rtree_gist work

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, Pennsylvania 19073

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, Pennsylvania 19073

"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, Pennsylvania 19073

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