From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, Daniele Orlandi <daniele(at)orlandi(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimizer & boolean syntax |
Date: | 2002-11-21 23:01:28 |
Message-ID: | Pine.LNX.4.33.0211211600390.23988-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 21 Nov 2002, Christopher Kings-Lynne wrote:
> > > I think his point is that they _should_ be equivalent. Surely there's
> > > something in the optimiser that discards '=true' stuff, like 'a=a'
> should be
> > > discarded?
> >
> > I figure that's what he meant, but it isn't what was said. ;)
> >
> > "col" isn't of the general form "indexkey op constant" or "constant op
> > indexkey" which I presume it's looking for given the comments in
> > indxpath.c. I'm not sure what the best way to make it work would be given
> > that presumably we'd want to make col IS TRUE/FALSE use an index at the
> > same time (since that appears to not do so as well).
>
> Not that I see the point of indexing booleans, but hey :)
also, in reference to my last message, even if the % was 50/50, if the
table was such that the bool was in a table next to a text field with 20k
or text in it, an index on the bool would be much faster to go through
than to seq scan the table.
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-11-21 23:02:41 | Re: Optimizer & boolean syntax |
Previous Message | Christopher Kings-Lynne | 2002-11-21 23:01:10 | Re: Optimizer & boolean syntax |