Skip site navigation (1) Skip section navigation (2)

Re: performance issue: logical operators are slow insideSQL function: missing optimalization?

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: performance issue: logical operators are slow insideSQL function: missing optimalization?
Date: 2010-08-29 15:46:27
Message-ID: 20100829154626.GA23912@svana.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Aug 29, 2010 at 11:23:29AM -0400, Tom Lane wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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(at)svana(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-08-29 18:08:54
Subject: Re: performance issue: logical operators are slow inside SQL function: missing optimalization?
Previous:From: Pavel StehuleDate: 2010-08-29 15:42:44
Subject: Re: performance issue: logical operators are slow inside SQL function: missing optimalization?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group