<br><br><div class="gmail_quote">On Mon, Dec 5, 2011 at 2:09 PM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@opengeo.org">pramsey@opengeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Dec 5, 2011 at 11:05 AM, C. Mundi <<a href="mailto:cmundi@gmail.com">cmundi@gmail.com</a>> wrote:<br>
<br>
> I get the impression that GiST hides a lot of<br>
> implementation details.  So I am hungry for details which will help me<br>
> assess postGIS/postgreSQL for my application.<br>
<br>
</div>This is the key point, and it is so: the physical implementation<br>
details are hidden behind the GiST API. As a result the R-Tree<br>
implementation is a "standard" one, not an R* (though the split method<br>
in Ang/Tan not Guttman). And as a result you can't do things like<br>
rebalance the tree as specified in the R* recipe. The GiST API really<br>
is quite narrow. You have the consistent function to control reads and<br>
the compress/picksplit controlling writes.<br>
<br>
So if you're looking for optimal tree construction you've come to the<br>
wrong place. The primary benefit of the PostGIS indexing system is not<br>
it's optimal nature but its existence: it's already here, you can<br>
insert and query data with simple SQL, it does do locking and<br>
consistent operations thanks to the postgresql infrastructure wrapped<br>
around it.<br>
<br>
As an architect my recommendation would be: since the development<br>
overhead in building your system from scratch will be quite high,<br>
investing the time into a load test on PostGIS first could save you a<br>
lot of time if it turns out that even our imperfect system is actually<br>
good enough to meet your needs.<br>
<br>
Best,<br>
<br>
P.<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</blockquote></div><br><br>Aha!  Paul, thank you very much.  This is a big part of what I need to know, even though it's not exactly what I wanted to hear.  I already know from testing that Ang/Tan splits can (not always but often enough to hurt in a way I can measure in money) crush the performance for the natural patterns of data+queries in the problem domain.  The fundamental reason is that the "minor nuisance" of occasionally suboptimal splits is "leveraged" across all compute cores. <br>
<br>So my new strategy is to live with the limits as you've suggested while looking for a suitable implementation of R*.  Since I'm not a database architect, any system I might build from scratch would be much worse than expensive -- it would be broken!  So I'd love to know about any practical R* implementations for any FOSS dB.  For that matter, I'd like to at least learn of commercial ones at well.<br>
<br>Many thanks for sharing your time and considerable insight!<br><br>Best,<br>Carlos<br><br>