2010/10/22 Teodor Sigaev <teodor@sigaev.ru>:
>> You can define the additional argument as providing all of the extra
>> info about how the operator is being used, and, if it's being used for
>> ordering, the details of the requested order. What is your thinking
>> on the matter?
>
> Maby be useful, but it seems to me to be a bit overengineering for now. GiST
> will not support knn-search with different than ASC NULLS LAST order in
> foresee future, because it stores NULLs in unmaintainable manner for
> different ordering: NULLs could be everywhere in tree. So, implementation of
> ASC NULLS FIRST requires to read whole tree to find all NULLs value first. I
> can imagine, how to reorganize tree to store NULLs together for
> single-column index, but not for multi-column index. Orders DESC NULLS
> LAST/FIRST requires to introduce two more "infinite" values: one to notion
> of distance more than +INF and another, non-negative, but less than zero
> distance.
I don't think it's overengineering, just because making core changes
to the planner is such a pain in the neck that we don't want to have
to come back and do it again any too soon, or at least we'd like them
to be as minor as possible. It's better to have one API break and be
done with it than maybe have to come back and do a second round of
code changes. And from what I can see it's not going to be that ugly.I'm trying to drum up some time to hack on it...
> Again, it could be useful for modification of GiST known as ordered GiST.
> But ordered GiST uses completely different tree traversal algorithm for
> search and insert, and it hasn't any benefits comparing with B-Tree and
> GiST. It's looks like an autogiro which successfully combines disadvantages
> of airplanes and helicopters :)
Heh. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company