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.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
