| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Tyler Hildebrandt <tyler(at)campbell-lange(dot)net> |
| Cc: | pgsql-performance(at)postgresql(dot)org, Sebastian Ritter <sebastian(at)campbell-lange(dot)net>, rory <rory(at)campbell-lange(dot)net> |
| Subject: | Re: Query timing increased from 3s to 55s when used as function instead of select |
| Date: | 2010-05-27 15:33:06 |
| Message-ID: | 4BFE90B2.2050604@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 21/05/2010 9:54 PM, Tyler Hildebrandt wrote:
> We're using a function that when run as a select statement outside of the
> function takes roughly 1.5s to complete whereas running an identical
> query within a function is taking around 55s to complete.
>
> We are lost as to why placing this query within a function as opposed to
> substituting the variables in a select statement is so drastically different.
This is a frequently asked question. It's the same issue as with
prepared queries, where the planner has to pick a more general plan when
it doesn't know the value of a parameter. The short answer is "work
around it by using EXECUTE ... USING to invoke your query dynamically".
( Oddly, this FAQ doesn't seem to be on the FAQ list at
http://wiki.postgresql.org/wiki/FAQ )
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konrad Garus | 2010-05-27 15:51:43 | Re: shared_buffers advice |
| Previous Message | Cédric Villemain | 2010-05-27 15:24:28 | Re: shared_buffers advice |