In benchmarks that I have done in the past comparing performance of 
Oracle and Postgres in our web application, I found that I got ~140 
requests/sec on Oracle and ~50 requests/sec on postgres.

The code path in my benchmark only issues one sql statement.  Since I 
know that Oracle caches query plans, I wanted to see the cost under 
postgres of the parse/plan/execute to see if the parsing and planing of 
the sql statement would account for the difference in performance 
between Oracle and postgres.

In a recent mail note to hackers, Tom mentioned the existence of the 
show_parser_stats, show_planner_stats, and show_executor_stats 
parameters in the postgresql.conf file.  So I turned them on ran my 
query a few times and here are the results:

average of 10 runs:
parsing  = .003537 sec (19.3%)*
planning = .009793 sec (53.5%)
execute  = .004967 sec (27.2%)

If Oracle is only incurring the execute cost for each query then this 
would explain the difference in performance between Oracle and Postgres.

This would lead me to conclude that the current proposed PREPARE/EXECUTE 
patch will be very useful to me.  (now I just need to find the time to 
test it).

thanks,
--Barry

* show_parser_stats prints out three separate timings: parser 
statistics, parse analysis statistics, rewriter statistics, the number 
.003537 is the sum of those three (.001086 + .002350 + .000101)
Sat, 13 Apr 2002 21:16:02 -0700
Barry Lind <barry@xythos.com>
cost of parse/plan/execute for one sample query
In testing Neil's PREPARE/EXECUTE patch on my test query, I found the 
parser complains that this query is not valid when using current 
sources.  The error I get is:

psql:testorig.sql:1: ERROR:  JOIN/ON clause refers to "xf2", which is 
not part of JOIN

I think the sql is valid (at least it has worked in 7.1 and 7.2).  Is 
this a bug?

thanks,
--Barry

PS.  I forgot to mention that the below performance numbers were done on 
7.2 (not current sources).

Barry Lind wrote:
> In benchmarks that I have done in the past comparing performance of 
> Oracle and Postgres in our web application, I found that I got ~140 
> requests/sec on Oracle and ~50 requests/sec on postgres.
> 
> The code path in my benchmark only issues one sql statement.  Since I 
> know that Oracle caches query plans, I wanted to see the cost under 
> postgres of the parse/plan/execute to see if the parsing and planing of 
> the sql statement would account for the difference in performance 
> between Oracle and postgres.
> 
> In a recent mail note to hackers, Tom mentioned the existence of the 
> show_parser_stats, show_planner_stats, and show_executor_stats 
> parameters in the postgresql.conf file.  So I turned them on ran my 
> query a few times and here are the results:
> 
> average of 10 runs:
> parsing  = .003537 sec (19.3%)*
> planning = .009793 sec (53.5%)
> execute  = .004967 sec (27.2%)
> 
> If Oracle is only incurring the execute cost for each query then this 
> would explain the difference in performance between Oracle and Postgres.
> 
> This would lead me to conclude that the current proposed PREPARE/EXECUTE 
> patch will be very useful to me.  (now I just need to find the time to 
> test it).
> 
> thanks,
> --Barry
> 
> * show_parser_stats prints out three separate timings: parser 
> statistics, parse analysis statistics, rewriter statistics, the number 
> .003537 is the sum of those three (.001086 + .002350 + .000101)
> 
>
Sat, 13 Apr 2002 22:27:24 -0700
Barry Lind <barry@xythos.com>
bug with current sources?  Re: cost of parse/plan/execute for one
	sample query
Barry Lind <barry@xythos.com> writes:
> In testing Neil's PREPARE/EXECUTE patch on my test query, I found the 
> parser complains that this query is not valid when using current 
> sources.  The error I get is:

> psql:testorig.sql:1: ERROR:  JOIN/ON clause refers to "xf2", which is 
> not part of JOIN

Hmm.  I have an open bug with sub-SELECTs inside a JOIN, but this
example doesn't look like it would trigger that.

> I think the sql is valid (at least it has worked in 7.1 and 7.2).  Is 
> this a bug?

Dunno.  Give me a test case (and no, I am *not* going to try to
reverse-engineer table schemas from that SELECT).

			regards, tom lane

Sun, 14 Apr 2002 13:11:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: bug with current sources? Re: cost of parse/plan/execute for one
	sample query
Tom,

OK here is a test case:

create table test1 (t1a int);
create table test2 (t2a int);
create table test3 (t3a int);
SELECT x2.t2a
FROM ((test1 t1 LEFT JOIN test2 t2 ON (t1.t1a = t2.t2a)) AS x1
LEFT OUTER JOIN test3 t3 ON (x1.t2a = t3.t3a)) AS x2
WHERE x2.t2a = 1;

The select works under 7.2, but gives the following error in 7.3:

ERROR:  JOIN/ON clause refers to "x1", which is not part of JOIN

thanks,
--Barry



Tom Lane wrote:
> Barry Lind <barry@xythos.com> writes:
> 
>>In testing Neil's PREPARE/EXECUTE patch on my test query, I found the 
>>parser complains that this query is not valid when using current 
>>sources.  The error I get is:
> 
> 
>>psql:testorig.sql:1: ERROR:  JOIN/ON clause refers to "xf2", which is 
>>not part of JOIN
> 
> 
> Hmm.  I have an open bug with sub-SELECTs inside a JOIN, but this
> example doesn't look like it would trigger that.
> 
> 
>>I think the sql is valid (at least it has worked in 7.1 and 7.2).  Is 
>>this a bug?
> 
> 
> Dunno.  Give me a test case (and no, I am *not* going to try to
> reverse-engineer table schemas from that SELECT).
> 
> 			regards, tom lane
> 



Sun, 14 Apr 2002 21:44:42 -0700
Barry Lind <barry@xythos.com>
Re: bug with current sources? Re: cost of parse/plan/execute
Barry Lind <barry@xythos.com> writes:
> OK here is a test case:

Looks like a bug, all right --- I must have introduced this when I redid
the handling of JOIN aliases a few weeks ago.   Will fix.

Thanks for the report.

			regards, tom lane

Mon, 15 Apr 2002 00:49:05 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: bug with current sources? Re: cost of parse/plan/execute for one
	sample query
Barry Lind <barry@xythos.com> writes:
> The select works under 7.2, but gives the following error in 7.3:
> ERROR:  JOIN/ON clause refers to "x1", which is not part of JOIN

I've committed a fix for this.  Thanks again.

			regards, tom lane

Mon, 15 Apr 2002 02:07:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: bug with current sources? Re: cost of parse/plan/execute for one
	sample query