| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
| 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:02:41 |
| Message-ID: | 006b01c291b2$17f73b80$6600a8c0@internal |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > "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.
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2002-11-21 23:34:53 | Re: performance of insert/delete/update |
| Previous Message | scott.marlowe | 2002-11-21 23:01:28 | Re: Optimizer & boolean syntax |