Re: Optimizer & boolean syntax

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Daniele Orlandi <daniele(at)orlandi(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimizer & boolean syntax
Date: 2002-11-22 15:59:27
Message-ID: Pine.LNX.4.33.0211220858540.25220-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 21 Nov 2002, Stephan Szabo wrote:

>
> On Thu, 21 Nov 2002, Christopher Kings-Lynne wrote:
>
> > > > > "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.
> >
> > Hmmm...I'm not sure about that. Postgres's storage strategry with text will
> > be to keep it in a side table (or you can use ALTER TABLE/SET STORAGE) and
> > it will only be retrieved if it's in the select parameters.
>
> True, but replace that text with 1500 integers. :)
>
> The only problem with the partial index solution is that it seems to still
> only work for the same method of asking for the result, so if you make an
> index where col=true, using col IS TRUE or col in a query doesn't seem to
> use it.

True. I always use the syntax:

select * from table where field IS TRUE

OR IS FALSE for consistency.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Scott Lamb 2002-11-22 16:36:11 Re: nested transactions
Previous Message scott.marlowe 2002-11-22 15:56:14 Re: performance of insert/delete/update