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

Re: Huge speed penalty using <>TRUE instead of =FALSE

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, Mikael Krantz <mk(at)zigamorph(dot)se>, Jan-Ivar Mellingen <jan-ivar(dot)mellingen(at)alreg(dot)no>
Subject: Re: Huge speed penalty using <>TRUE instead of =FALSE
Date: 2009-07-17 16:12:28
Message-ID: FCA5FE46-3527-4068-987B-E07773818627@mit.edu (view raw or flat)
Thread:
Lists: pgsql-bugs
I don't think it even has to be so specific. We should just always  
rewrite bool <> bool into bool = NOT bool.


Hmm. That only has a 50/50 chance of  creating an indexable clause.  
Perhaps we could even rewrite it as "a = NOT b AND NOT a = b".

-- 
Greg

On 2009-07-17, at 3:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> ... But again, this is data type specific knowledge.
>
> Actually, now that I think about it, the planner already has
> datatype-specific knowledge about boolean equality (see
> simplify_boolean_equality).  It would take just a few more lines of  
> code
> there to recognize "x <> true" and "x <> false" as additional variant
> spellings of the generic "x" or "NOT x" constructs.  Not sure if it's
> worth the trouble though; how many people really write such things?
>
> If you really wanted to take it to extremes, you could also reduce
> cases like "x > false", but that's starting to get a bit silly.
>
>            regards, tom lane
>
> -- 
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-17 16:17:56
Subject: Re: bug or simply not enough stack space?
Previous:From: Tom LaneDate: 2009-07-17 14:21:43
Subject: Re: Huge speed penalty using <>TRUE instead of =FALSE

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