Re: pgsql-server/doc TODO

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server/doc TODO
Date: 2004-05-20 03:21:38
Message-ID: 24977.1085023298@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> momjian(at)svr1(dot)postgresql(dot)org (Bruce Momjian) writes:
>>> Add:
>>> * Allow col IS TRUE/FALSE use an index like col = TRUE/FALSE
>>
>> They don't have the same semantics.

> Oh, they don't? Nulls?

Right.

On second thought it might be possible to optimize this in a similar
fashion to the IN optimizations, viz only at top level of WHERE, so that
you can pretend NULL is the same as FALSE. But it needs some careful
thought.

A possibly more relevant issue is that indexes on boolean columns are
seldom of any value anyway, and so optimizing behavior for them seems
pretty far down the priority list. In my experience it's more useful to
create an index on another column(s) with the boolean condition as a
partial-index predicate. In this context you can spell the condition
however you like, it just has to be the same spelling in queries as in
the index definition...

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2004-05-20 03:27:36 pgsql-server/doc TODO
Previous Message Bruce Momjian 2004-05-20 03:05:26 Re: pgsql-server/doc TODO