Janko Richter <[EMAIL PROTECTED]> 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
