Re: Query runs in 335ms; function in 100,239ms : date problem?

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

In response to

Browse pgsql-general by date

  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?