Re: R-Tree operators

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: R-Tree operators
Date: 2004-09-17 21:35:46
Message-ID: 87pt4ko9xp.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-09-17 21:51:43 Re: R-Tree operators
Previous Message Tom Lane 2004-09-17 21:33:32 Re: Disabling bgwriter on my notebook