<br>Hi.  This is my first post.  As such, feedback is especially welcome.<br><br>I just posted a question on the postgres-users list which maybe I should have sent here.<br><br>Short version: I am not a database expert, much less a GiS expert.  I have a problem which looks like it needs a GiS solution.  I will have hundreds or more "compute" nodes rapidly querying a central "data" node serving a spatial database of bounding boxes in 3D.  Based on very limited experience and a bit of reading, <br>
<br>Additional details include high (20%) turnover of boxes in the database during a "run"; no permissible assumptions on the distributions of box locations, sizes or aspect ratios; and no assumptions on the spatio-temporal coherence of queries viewed as a time-sequence of spatial events.  The turnover rules out priority R trees, and the lack of coherence means that cache performance will probably be poor in any solution and therefore need not be a primary concern.<br>
<br>I think an "R*-link tree" combining the characteristics of R* (esp. better leaf 
& page separation and lower aspect-ratio pages compared to R) with 
linking [1] to support high concurrency are what I need.  Perhaps this or something better is already implemented in postGIS?<br>
<br>But maybe I'm all wrong.  So I want to start learning about<br><br><div style="margin-left: 40px;">(a) what are the current options and tradeoffs for high-concurrency spatial databases;<br>(b) how can postGIS address concurrency in the context above.<br>
</div><br>My understanding (?) is that postgreSQL supports essential B-tree, R-tree (plain R-tree?) and GiST indexes.  And as I read through the user-oriented manual for postGIS 2,.0, I get the impression that GiST hides a lot of implementation details.  So I am hungry for details which will help me assess postGIS/postgreSQL for my application.<br>
<br>I know this is a lot to ask in an introductory question, but I hope I'm also clear and concise.<br><br>Thanks!<br>Carlos<br><br>[1] Marcel Kornacker and Douglas Banks. High-Concurrency Locking in R-Trees. (1995)<br>
<br>