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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly