<p>Thank you very much, Jochen. This can at least teach me how much trouble I'm getting into!</p>
<p>Cheers,<br>
Carlos<br>
</p>
<div class="gmail_quote">On Dec 5, 2011 3:29 PM, "Jochen Albrecht" <<a href="mailto:jochen.albrecht@gmail.com">jochen.albrecht@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Have a look at <a href="http://www.cs.purdue.edu/spgist" target="_blank">http://www.cs.purdue.edu/spgist</a>, Carlos. It was written for a dated version of PostgreSQL but you given your background, it may be less work that building something from scratch. It is a fairly low-level implementation of Samet's 2006 bible and hence allows to derive R* trees according to section 2.1.5.2 of the book.</div>
<div>Cheers,</div><div> Jochen</div><div><br></div><br><div class="gmail_quote">On Mon, Dec 5, 2011 at 4:54 PM, C. Mundi <span dir="ltr"><<a href="mailto:cmundi@gmail.com" target="_blank">cmundi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><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" target="_blank">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>On Mon, Dec 5, 2011 at 11:05 AM, C. Mundi <<a href="mailto:cmundi@gmail.com" target="_blank">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" target="_blank">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></div></div>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>
<br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net" target="_blank">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>
<br></blockquote></div><br>
<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>
<br></blockquote></div>