PQLIB: Prepared statement speed oddity

Поиск
Список
Период
Сортировка
От Mark Simonetti
Тема PQLIB: Prepared statement speed oddity
Дата
Msg-id 56AF56F8.2010303@opalsoftware.co.uk
обсуждение исходный текст
Ответ на BUG #12465: Materialized view dump restoration issue  (jeff.casavant@gmail.com)
Ответы Re: PQLIB: Prepared statement speed oddity
Список 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.
--

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Vladimir Zvagolskiy
Дата:
Сообщение: Re: BUG #13898: ecpg complains on nested comments in /usr/pgsql-9.4/include/informix/esql/datetime.h
Следующее
От: Mark Simonetti
Дата:
Сообщение: Re: PQLIB: Prepared statement speed oddity