Re: R-Tree operators - Mailing list pgsql-hackers

From Greg Stark
Subject Re: R-Tree operators
Date
Msg-id 87pt4ko9xp.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: R-Tree operators  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: R-Tree operators  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > I don't understand what overlap_{left,right} are supposed to mean.
> 
> In this thread:
> http://archives.postgresql.org/pgsql-general/2004-03/msg01135.php
> we had decided that the rtree stuff is not only poorly documented
> but actively broken.  I had thought that Bill White was going to do
> some work on the problem, but we've not heard back from him ...

Well that's regarding existing the rtree operator classes for existing
geometric types. What I'm wondering is what invariants I have to maintain if
I'm defining a new operator class.

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? For building the index it uses the support functions
(union,intersection,size)?

Part of the confusion here is that left,right,overleft,overright only make
sense for 1-dimension cases like intervals. For more dimensions it seems they
make little sense at all. I would be happy if I could just leave them out. As
long as the rtree code can still build the index fine using the support
functions and just not handle access patterns using them I'll be fine.

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Disabling bgwriter on my notebook
Next
From: Tom Lane
Date:
Subject: Re: R-Tree operators