[postgis-users] High Concurrency R* in GiST?

[C. Mundi]

Hi.  This is my first post.  As such, feedback is especially welcome.

I just posted a question on the postgres-users list which maybe I should
have sent here.

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,

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.

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?

But maybe I'm all wrong.  So I want to start learning about

(a) what are the current options and tradeoffs for high-concurrency spatial
databases;
(b) how can postGIS address concurrency in the context above.

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.

I know this is a lot to ask in an introductory question, but I hope I'm
also clear and concise.

Thanks!
Carlos

[1] Marcel Kornacker and Douglas Banks. High-Concurrency Locking in
R-Trees. (1995)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20111205/65bc4c38/attachment.html>