PQLIB: Prepared statement speed oddity

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.
--

In response to

Responses

Browse pgsql-bugs by date

  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