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
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 |