Re: Question about rtrees (overleft replacing left in nodes)

Tom Lane wrote:

> Good point. You can force it by setting enable_seqscan to false, but
> otherwise it's unlikely to happen.

Ah, didn't know about enable_seqscan, thanks.

> It seems to me that the operator rtree actually wants is best thought of
> as "is not to right of" (resp. "is not to left of"). The reference to
> overlapping is misleading, at least when thinking in 2 or more
> dimensions, since a box that is completely above or below the reference
> box could still "overlap" in the 1-dimensional sense being used here.
> So reasonable operator names would be !>> and !<< respectively.

Well, the rtree implementation is 1-D, so I've been thinking in 1-D.
But I agree those are reasonable ... come to think of it, you could fill
in the commutator and negator attributes, right? (or am I missing the
boundary case here; I haven't really looked yet)

> And even when thinking in 1-D,
> "overlaps" has a different meaning than what the code is doing, anyway.

That was what originally caught my eye.

> So it's clear that we should also change either the code or the
> documentation for the existing operators. If we are going to add new
> operators then I'd favor leaving the existing code alone as a
> potentially useful behavior, but fixing the documentation.

and of course the old operators wouldn't be used in the operator class
search strategies, if I'm understanding correctly.

> I can't think of an equally succinct definition of what the operators
> really do though. Comments?

I think "not to the left of" and "not to the right of" are sufficiently
succinct. That they may not see much user application may not be
relevant, if they are required to properly implement << and >> on rtrees.

> BTW, it occurs to me we should add rtree opclasses associated with
> Y-dimension tests (is below, etc) ... or should there be more members of
> an rtree opclass than there are now?

I'm not familiar enough with rtrees to know for sure, but it appears
that the indexing itself is "dimension agnostic", only caring about
union (well, bounding region), intersection, and size. Thus, you could
add as many dimensions as you wanted, you'd just need 4d+4 search
strategy operators (&&, ~=, ~, and @ being non-positional) in the
opclass. It would be nice if pgsql supported a variable number of
strategy operators, but this would probably mean changing the order
(putting the 4 nonpositionals first) and rewriting a lot of code.