Thread: rtree_gist work
Is currently anybody working on extending rtree_gist? I have seen, it is moved to core now. I had a look at it and because I have some experience with PGSQL's Gist API, I would do the job. Regards,Janko Richter
Janko Richter wrote: > Is currently anybody working on extending rtree_gist? I have seen, it is moved > to core now. I had a look at it and because I have some experience with PGSQL's Gist API, > I would do the job. I don't think anyone is working in improving it, no. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > Janko Richter wrote: > >>Is currently anybody working on extending rtree_gist? I have seen, it is moved >>to core now. I had a look at it and because I have some experience with PGSQL's Gist API, >>I would do the job. > > > I don't think anyone is working in improving it, no. > OK. If I start developing now, is there a chance to put it in 8.1 or is it better to do it for 8.2. I'm not sure about feature freezing of 8.1. Implementing may take 1 or 2 weeks. Regards, Janko Richter
Janko Richter wrote: > Bruce Momjian wrote: > > >Janko Richter wrote: > > > > > >>Is currently anybody working on extending rtree_gist? I have seen, it is moved > >>to core now. I had a look at it and because I have some experience with PGSQL's Gist API, > >>I would do the job. > >> > >> > > > >I don't think anyone is working in improving it, no. > > > > > > > OK. If I start developing now, is there a chance to put it in 8.1 or is > it better to do it for 8.2. I'm not sure about feature freezing of 8.1. > Implementing may take 1 or 2 weeks. You only have 1-2 days to make it into 8.1, -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Janko Richter" <jankorichter@yahoo.de> writes:
> OK. If I start developing now, is there a chance to put it in 8.1 or is it
> better to do it for 8.2. I'm not sure about feature freezing of 8.1.
Feature freeze for 8.1 is on Monday.
regards, tom lane
Janko Richter <jankorichter@yahoo.de> writes:
> Is currently anybody working on extending rtree_gist? I have seen, it is moved
> to core now. I had a look at it and because I have some experience with PGSQL's Gist API,
> I would do the job.
What changes have you got in mind exactly?
regards, tom lane
Tom Lane wrote: > Janko Richter <jankorichter@yahoo.de> writes: > >>Is currently anybody working on extending rtree_gist? I have seen, it is moved >>to core now. I had a look at it and because I have some experience with PGSQL's Gist API, >>I would do the job. > > > What changes have you got in mind exactly? > At first, I would implement all RTREE supported operators in GIST. Then, the GIST implementation may be a full replacement/alternative for RTREE. Futhermore, I would implement all relationship operators, which are unsupported in RTREE using GIST. As a consequence, the TODO item: - Add rtree index support for line, lseg, path, point can be marked as "done". Regards, Janko Richter
Janko Richter <jankorichter@yahoo.de> writes:
> Tom Lane wrote:
>> What changes have you got in mind exactly?
> At first, I would implement all RTREE supported operators in GIST.
> Then, the GIST implementation may be a full replacement/alternative for RTREE.
That's already done.
> Futhermore, I would implement all relationship operators, which are unsupported
> in RTREE using GIST. As a consequence, the TODO item:
> - Add rtree index support for line, lseg, path, point
> can be marked as "done".
I'm not sure that you want to think of this as a direct copy of "what
rtree would do". The set of interesting operators isn't really the same
for all these types ... which was hard or impossible to support in rtree
but is trivial in GIST. As an example, contains/contained in are pretty
meaningless for two points; but it would be very useful to directly
support queries like "point is contained in box?", "point is contained
in circle?" on a point column. There are some cross-type operators like
these that ought to be added to the existing opclasses as well. So I
think the first part of the job is to figure out exactly what operators
to support for each datatype.
(The TODO item as written is pretty much a dead letter anyway: nobody
is going to do any more work on rtree. It should probably read "add
more gist index support for geometric data types".)
regards, tom lane
Tom Lane wrote: > (The TODO item as written is pretty much a dead letter anyway: nobody > is going to do any more work on rtree. It should probably read "add > more gist index support for geometric data types".) TODO updated. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > I'm not sure that you want to think of this as a direct copy of "what > rtree would do". The set of interesting operators isn't really the same > for all these types ... which was hard or impossible to support in rtree > but is trivial in GIST. As an example, contains/contained in are pretty > meaningless for two points; but it would be very useful to directly > support queries like "point is contained in box?", "point is contained > in circle?" on a point column. There are some cross-type operators like > these that ought to be added to the existing opclasses as well. So I > think the first part of the job is to figure out exactly what operators > to support for each datatype. > > I know about the problems. I have implemented similar index for spherical objects using GIST ( http://gborg.postgresql.org/project/pgsphere/ ). It is more complicated. There, I had to implement the operators plus GIST support. There are a lot of cross-type operators as well. So, I'm looking forward to solve the outstanding problems. Of course, I will implement support of queries like "point is contained in box?". BTW: I did a test/exercise some hours ago. The query "point is contained in box?" is already using the GIST index in my CVS-Box. Currently, I don't see any problem. My first question was "Is anybody working on it?". Because nobody does, I would make a concept now in detail and start to implement it. Because it is for 8.2, I have a little bit time. Regards, Janko Richter
Tom Lane <tgl@sss.pgh.pa.us> writes: > As an example, contains/contained in are pretty meaningless for two points; > but it would be very useful to directly support queries like "point is > contained in box?", "point is contained in circle?" on a point column. Just as a bit of supporting anecdotal evidence. I ended up storing longitude and latitude redundantly in my tables as a point and also as a 0-area box just so I could use the box <contains> box operator because there's no <box> contains <point> operator. -- greg
Greg Stark wrote:
> Just as a bit of supporting anecdotal evidence. I ended up storing longitude
> and latitude redundantly in my tables as a point and also as a 0-area box just
> so I could use the box <contains> box operator because there's no <box>
> contains <point> operator.
If necessary, I will add missing operators.
Regards, Janko Richter
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de