From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Tomas Vondra" <tv(at)fuzzy(dot)cz> |
Cc: | "Rory Campbell-Lange" <rory(at)campbell-lange(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query runs in 335ms; function in 100,239ms : date problem? |
Date: | 2011-09-06 15:10:54 |
Message-ID: | 6839.1315321854@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Tomas Vondra" <tv(at)fuzzy(dot)cz> writes:
> On 6 Z 2011, 0:27, Rory Campbell-Lange wrote:
>> The prepared query runs in almost exactly the same time as the function,
>> but thanks for the suggestion. A very useful aspect of it is that I was
>> able to get the EXPLAIN output which I guess gives a fairly good picture
>> of the plan used for the function.
> Well, my point was that the queries wrapped in functions are executed just
> like prepared statements. And because prepared queries do not use
> parameter values to optimize the plan, the result may be worse compared to
> queries with literal parameters. So I was not expecting an improvement, I
> was merely trying to show the problem.
Right. The actual fix is to use EXECUTE so you force a new plan to be
generated each time. If you use EXECUTE USING to insert the parameter
values, you can avoid most of the notational mess this would otherwise
imply, as well as the risk of SQL-injection bugs from failing to quote
parameter values safely.
I'm hoping that 9.2 will be smart enough to not need such workarounds,
but that's where things stand at the moment.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Susan Cassidy | 2011-09-06 16:05:15 | Backend process that won't die |
Previous Message | Chris Redekop | 2011-09-06 15:05:51 | Demoting master to slave without an rsync...is it safe? |