Re: R-Tree operators

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I'm starting to get a better idea of what's going on here though. Is it the
> case that the operators in the operator class are only used when actually
> doing an index scan?

Not even that, really. The operator class is what the planner uses to
detect that a WHERE clause is potentially implementable by an indexscan:
if you have "var OP pseudoconstant" where OP is an operator in the
opclass of an index on VAR, then this is indexscannable. The indexscan
plan just says to the index AM "here's the WHERE clause, do something
with it". It's entirely possible that the index AM will never execute
the operator from the WHERE clause directly --- it could rely entirely
on the support functions. (For example, btree could obviously do
everything it needs to do by examining the results of the
3-way-comparator support function. I think there are one or two places
where it finds it convenient to use the actual WHERE-clause operator's
implementation function, but in the main it uses the support function.)
On the other hand the index AM is also allowed to transpose things and
substitute use of one operator for another --- so no, you can't just
partially implement an opclass and expect it to work.

I'm not familiar enough with the rtree AM to lay out for you how those
general comments apply to rtree in particular, but that should give you
the lay of the land. I do recall that rtree does some operator
substitution to obtain the correct tests to use at upper tree levels.

The behavior of the opclass operator members absolutely does have to be
consistent with the support functions, which means that yes there are
very specific semantic requirements on what each one does relative to
the support functions and other members of its opclass. In the thread
I pointed you to, we had made some progress on understanding just what
rtree expects the semantics to be, but none of that has gotten
transposed into the code or docs yet.

> Part of the confusion here is that left,right,overleft,overright only make
> sense for 1-dimension cases like intervals.

See the thread. I had personally always assumed that rtree was for 2-D
objects, but it seems like this aspect of the opclass definition handles
just one dimension. I'd like to see that improved. Or if it's
fundamental, we need to provide pairs of rtree opclasses for
horizontally and vertically aligned inquiries ...

regards, tom lane