> > ... there's no real reason not to support indexes on booleans, is
> > there?
afaict the only case where this would be a win is if there is a *very*
skewed distribution of boolean values, and you *only* want the
uncommon one. Otherwise, looking up half the rows in a table via index
has got to be worse than just scanning the table.
> Not that I can see. Care to whip up the index support? I think the
> only actual new code needed is a three-way-compare function (return -1,
> 0, or +1 according as a < b, a = b, a > b). Then you need to make up
> the appropriate rows in pg_amop and related tables. See the "xindex"
> chapter of the documentation.
> (It occurs to me that performance would probably suck, however, because
> btree doesn't handle lots of equal keys very efficiently. Fixing that
> is on the TODO list...)
... And performance will suck anyway (see above) :)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California