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. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
