Re: Why is NULL not indexable? - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Why is NULL not indexable?
Date
Msg-id 20010628111541.A13914@svana.org
Whole thread Raw
In response to Re: Why is NULL not indexable?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why is NULL not indexable?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Wed, Jun 27, 2001 at 10:04:23AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > Ok, I can see at least part of the problem now. You could make two operators
> > 'is' and 'isnot' and have them equivalent to '=' and '!=' except in the case
> > of nulls. The index code is doing something like this anyway already.
>
> Btree does that, but it might not work at all for non-btree indexes.
> Besides, you'd need a pair of such operators for every indexable
> datatype.  I'd prefer to see the notion of IS (NOT) NULL directly
> expressed in some fashion in the ScanKey representation.  Phony
> operators corresponding to the (existing) functions nullvalue and
> nonnullvalue might work.

So the options are to either find a way to make the strategy code handle
unary operators, or to make binary operators is and isnot that the parser
uses when it sees an IS NULL expression.

You'd want to add two more strategies to represent the relationsationships.
This is not going to be quick, that's for sure. BTW, is there a way of
dumping the contents of an index, for example the way an index scan would
see it? This would mean you could see whether the index was storing the data
correctly in the first place.

> > Is there any documentation describing how this all works?
> http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/xindex.html

Thanks, that made it much clearer. That page didn't show up on google, which
is why I didn't find it. So index types define their strategies and the
*_ops define the relationships between the strategies and the operators.

> > As a side note, the partial index stuff seems to be still perfectly fine in
> > the indexing code, you say it's the planner that doesn't handle it right?
>
> The planner code is still there.  Someone once ripped out the WHERE
> clause from CREATE INDEX in the grammar, for reasons undocumented and
> now forgotten.  It's hard to guess what might need to be fixed after
> adding that back --- surely all that code is now suffering bit-rot to
> some extent.

So I guess the first step is to add that back and see what breaks? Sounds
like fun :)

--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
- Artificial Intelligence is the science of making computers that behave
- like the ones in the movies.

pgsql-general by date:

Previous
From: Alex Pilosov
Date:
Subject: Re: Blobs in PostgreSQL
Next
From: "Thomas T. Veldhouse"
Date:
Subject: Problem with null timestamp fields