Re: performance issue: logical operators are slow inside SQL function: missing optimalization? - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: performance issue: logical operators are slow inside SQL function: missing optimalization?
Date
Msg-id 20100829154626.GA23912@svana.org
Whole thread Raw
In response to Re: performance issue: logical operators are slow inside SQL function: missing optimalization?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: performance issue: logical operators are slow inside SQL function: missing optimalization?
List pgsql-hackers
On Sun, Aug 29, 2010 at 11:23:29AM -0400, Tom Lane wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > I understand now. So it means general advice - don't use a boolean
> > operators in SQL function? This issue should be documented somewhere?
>
> It has nothing to do with boolean operators, just double evaluation.

I was wondering, wouldn't it be possible to avoid the double evaluation
by simply creating an extra slot for the intermediate value. So you
get:

$1 = CASE WHEN random() < 0.5 THEN NULL ELSE 'x' END
$2 = $1 IS NULL or $1 = ''

Sort of the way WITH works, but then for parts of expressions.

I don't believe currently expressions can refer to Vars at the same
level (it would make projections somewhat messy) but if you could
fix that you could avoid the double evaluation and still have decent
performance, right?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
>                                       - Charles de Gaulle

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: performance issue: logical operators are slow inside SQL function: missing optimalization?
Next
From: Tom Lane
Date:
Subject: Re: performance issue: logical operators are slow inside SQL function: missing optimalization?