cost of parse/plan/execute for one sample query
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)
Attachments:
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:
Show quoted text
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)
Attachments:
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
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:
Show quoted text
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 JOINHmm. 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
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
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