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 по дате отправления: