Re: knngist patch support

On Fri, Feb 12, 2010 at 3:44 PM, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> wrote:
> We tried to find compromise for 9.0 (Tom suggests contrib module), but all
> variants are ugly and bring incompatibility in future. If there are no
> hackers
> willing/capable to review our patches, then, please,  help us  how to save
> neighbourhood search without incompatibility in future.

Here's what I've gathered from my read through this patch. Let me
know if it's right:

In CVS HEAD, if an AM is marked amcanorder, that means that the index
defines some kind of intrinsic order over the tuples so that, from a
given starting point, it makes sense to talk about scanning either
forward or backward. GIST indices don't have an intrinsic notion of
ordering, but the structure of the index does lend itself to finding
index tuples that are "nearby" to some specified point. So this patch
wants to introduce the notion of an AM that is marked amcanorderbyop
to accelerate queries that order by <indexed column> <op> <constant>.

To do that, we need some way of recognizing which operators are
candidates for this optimization. This patch implements that by
putting the relevant operators into the operator class. That requires
relaxing the rule that operator class operators must return bool; so
instead when the AM is marked amcanorderbyop we allow the operator
class operators to return any type with a default btree operator
class.

Does that sound right?

Tom remarked in another email that he wasn't too happy with the
opclass changes. They seem kind of grotty to me, too, but I don't
immediately have a better idea. My fear is that there may be places
in the code that rely on opclass operators only ever returning bool,
and that changing that may break things. It also feels like allowing
non-bool-returning opclass members only for this one specific case is
kind of a hack: is this an instance of some more general problem that
we ought to be solving in some more general way? Not sure.

In any case, it seems to me that figuring out how we're going to solve
the problem of marking the operators (or otherwise identifying the
expression trees) that are index-optimizable is the key issue for this
patch. If we can agree on that, the rest should be a SMOP.

...Robert