From: | Mark Simonetti <marks(at)opalsoftware(dot)co(dot)uk> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | PQLIB: Prepared statement speed oddity |
Date: | 2016-02-01 13:00:40 |
Message-ID: | 56AF56F8.2010303@opalsoftware.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
I'm having a strange problem using prepared statements. I am using them
in an effort to eliminate large planning times.
I will try and break the problem down : -
1) A query in my database takes over half a second to plan, but often
only 5ms to 80ms to run depending on the parameter: -
test=# explain analyze select * from myview where site_code = 'M3374';
..
Planning time: 606.590 ms
Execution time: 83.735 ms
(203 rows)
test=# explain analyze select * from myview where site_code = 'M3373';
<=== NOTE different parameter
..
Planning time: 624.158 ms
Execution time: 5.275 ms
(213 rows)
2) To stop my application feeling sluggish, I decided to try using a
prepared statement.
test=# prepare myprep as select * from myview where site_code = $1;
PREPARE
3) Dissapointingly the first few runs still have the planning pause, but
gives the same execution result as expected:
test=# explain analyze execute myprep('M3374');
..
Execution time: 83.596 ms
(202 rows)
4) Probably the first 5 or 6 runs are like this; they have the same
planning pause of over half a second, even though I've "prepared" it...
5) Then after that I suddenly get amazing results, and even the
execution speed drops substantially for some parameters: -
test=# explain analyze execute myprep('M3374');
..
Execution time: 40.273 ms
(208 rows)
Half the execution speed!
So far so good...
6) However, if I start again but instead of executing myprep('M3374')
first, I instead execute myprep('M3373') first, the plan seems to never
get cached.
DEALLOCATE myprep;
test=# prepare myprep as select * from myview where site_code = $1;
PREPARE
test=# explain analyze select * from myview where site_code = 'M3373';
Half second pause for planning, 5ms exec time.
Repeat the query 5 times.. 10 times.. 20 times.. never changes, never
improves. Sometimes on the 5th or 6th the planning actually seems to
take over 1 second, then go back to normal.
Again, it is STILL only 5ms execution time (only returns 1 row), but
there is that annoying planning pause even though it is prepared, and
ran many times.. it is not caching the plan.
7) To re-iterate, once it is cached (using the 'M3374' parameter) it is
*very* fast with all parameters, but obviously I cannot rely on this in
a user environment.
I hope the problem makes sense.
Thanks in advance,
Mark.
--
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Simonetti | 2016-02-01 13:04:06 | Re: PQLIB: Prepared statement speed oddity |
Previous Message | Michael Meskes | 2016-02-01 12:16:20 | Re: BUG #13898: ecpg complains on nested comments in /usr/pgsql-9.4/include/informix/esql/datetime.h |