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.
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 |