<div dir="ltr"><div><div><div>Hey,<br>I don't know if I understood you right, <br></div>wouldn't it be conceptually possible to extend this index to _non overlaping_ bbox?<br></div><div><br>In this case it would gain much more usefulness.<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>I guess Quad tree are better than R tree only with simple non overlapping geom?</div></blockquote></blockquote><div><br></div>Cheers,<br></div>Rémi-C<br><div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-01 10:01 GMT+02:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Tue, Sep 30, 2014 at 11:45:23AM -0700, Paul Ramsey wrote:<br>
> Hey all,<br>
><br>
> So, I’ve now got a working sp-gist implementation<br>
><br>
> <a href="https://github.com/pramsey/postgis/tree/spgist/" target="_blank">https://github.com/pramsey/postgis/tree/spgist/</a><br>
><br>
> (Build and install, and after enabling postgis also run the commands in gserialized_spgist_2d.sql to add the spgist functions and opclass)<br>
><br>
> 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).<br>
><br>
> 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)<br>
><br>
> 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.<br>
<br>
</div></div>I've recently extended our estimator to work on functional indexes, so<br>
while we can't support non-point geometries we can always create index<br>
on function that convert them to points (ST_Centroid, or whatever).<br>
<br>
Or where would you put a large rectangle in a space-partitioned index ?<br>
Is there support for having multiple index rows for a single table row ?<br>
<br>
--strk;<br>
<br>
 ()  ASCII ribbon campaign  --  Keep it simple !<br>
 /\  <a href="http://strk.keybit.net/rants/ascii_mails.txt" target="_blank">http://strk.keybit.net/rants/ascii_mails.txt</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a></blockquote></div><br></div></div>