Hannu Krosing <hannu@tm.ee> writes:
> and I can't see why btree stores them (as it seems to do judging by the
> index file size) - at least it does not use it for searching for "IS
> NULL"
That's another thing that needs improvement ;-). Seems to me it should
be able to do that.
The reason why btree *has* to be able to deal with null entries is to
cope with multi-column indexes; you don't want it refusing to index a
row at all just because some of the columns are null. The others don't
currently handle multi-column indexes, so they're not really forced
to deal with that issue.
From a purely semantic point of view I'm not sure why Oleg is worried
about being able to store nulls in a GiST index ... seems like leaving
them out is OK, modulo the occasional complaint from VACUUM's
insufficiently intelligent tuple-count comparison ...
regards, tom lane
