[postgis-devel] SP-GIST: what to do

[Rémi Cura]

Hey,
I don't know if I understood you right,
wouldn't it be conceptually possible to extend this index to _non
overlaping_ bbox?

In this case it would gain much more usefulness.

> I guess Quad tree are better than R tree only with simple non overlapping
>> geom?
>>
>
Cheers,
Rémi-C


2014-10-01 10:01 GMT+02:00 Sandro Santilli <strk at keybit.net>:

> On Tue, Sep 30, 2014 at 11:45:23AM -0700, Paul Ramsey wrote:
> > Hey all,
> >
> > So, I’ve now got a working sp-gist implementation
> >
> > https://github.com/pramsey/postgis/tree/spgist/
> >
> > (Build and install, and after enabling postgis also run the commands
> in gserialized_spgist_2d.sql to add the spgist functions and opclass)
> >
> > This is a copy of the quadtree implementation Teodor put into PgSQL, but
> bound to our ‘geometry’ type. It is also restricted to points only (though,
> non-optimally, I cannot throw a “not a point” error until I get into the
> picksplit routine, so it’s possible to build a small index on non-point
> features… just how to handle that corner case is something I have yet to
> figure out).
> >
> > The question is whether to continue to pursue this work for 2.2. Given
> the lack of a “compress” hook for spgist, support for anything other than
> points seems problematic. Similarly, the corner case above could have
> potentially deleterious effects. Also, since we have a cast from
> geometry::point (for geometries that are points), it’s possible for people
> to build functional spgist indexes *already*, if they like (though they
> won’t have as good stats/planning as geometry, since the spatial stats code
> in postgresql proper is lacking)
> >
> > I feel like the lack of support for all geometry variants, and the
> inability to cleanly restrict the index to just a point variant in
> combination make spending more effort on a direct geometry binding probably
> not worth it, though I’m willing to entertain counter arguments.
>
> I've recently extended our estimator to work on functional indexes, so
> while we can't support non-point geometries we can always create index
> on function that convert them to points (ST_Centroid, or whatever).
>
> Or where would you put a large rectangle in a space-partitioned index ?
> Is there support for having multiple index rows for a single table row ?
>
> --strk;
>
>  ()  ASCII ribbon campaign  --  Keep it simple !
>  /\  http://strk.keybit.net/rants/ascii_mails.txt
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20141001/fef29e8a/attachment.html>