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

Howard Butler hobu.inc at gmail.com
Tue Dec 6 09:51:01 PST 2011


libspatialindex does have thread safety and support for using custom index data storage.  One of the Python Rtree users has implemented ZODB storage of libspatialindex data, for example, so the blocks should be in place to theoretically support this.

Howard

On Dec 6, 2011, at 11:46 AM, C. Mundi wrote:

> Thanks, Howard.  That actually may help.  We are looking at possibly borrowing some talent from another group who is experienced in db internals and may be able to piece something together.  If that happens I will advocate giving it back to the community, whatever "it" becomes.
> 
> Thanks!
> Carlos
> 
> On Dec 6, 2011 10:20 AM, "Howard Butler" <hobu.inc at gmail.com> wrote:
> http://libspatialindex.github.com/ is a C/C++ implementation of a R* with quadratic splitting that supports bulk loading. It doesn't integrate with PostGIS, of course, but you may find it useful.
> 
> Additionally, http://toblerity.github.com/rtree/ is available to allow you to play with it in Python for rapid prototyping.
> 
> Hope this helps,
> 
> Howard
> 
> On Dec 6, 2011, at 10:58 AM, C. Mundi wrote:
> 
> > Indeed, I am a strong believer that "worse is better" in the absence of evidence.  It just so happens that I have evidence that R* is significantly advantaged over plain R in my particular application.   So the question becomes, can I gain enough productivity elsewhere to make the impact of R v. R* moot.  I expect I can, now that the hope of free lunch has been taken away.  :)
> >
> > Thanks for the link -- it is one of my favorites.
> >
> > Carlos
> > On Dec 6, 2011 2:44 AM, "Jan Hartmann" <j.l.h.hartmann at uva.nl> wrote:
> > "Worse is better" :-) See:
> >
> > http://www.jwz.org/doc/worse-is-better.html
> >
> > Cheers,
> >
> > Jan
> >
> > On 12/05/2011 10:09 PM, Paul Ramsey wrote:
> >> On Mon, Dec 5, 2011 at 11:05 AM, C. Mundi <cmundi at gmail.com>
> >>  wrote:
> >>
> >>
> >>> 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.
> >>>
> >> This is the key point, and it is so: the physical implementation
> >> details are hidden behind the GiST API. As a result the R-Tree
> >> implementation is a "standard" one, not an R* (though the split method
> >> in Ang/Tan not Guttman). And as a result you can't do things like
> >> rebalance the tree as specified in the R* recipe. The GiST API really
> >> is quite narrow. You have the consistent function to control reads and
> >> the compress/picksplit controlling writes.
> >>
> >> So if you're looking for optimal tree construction you've come to the
> >> wrong place. The primary benefit of the PostGIS indexing system is not
> >> it's optimal nature but its existence: it's already here, you can
> >> insert and query data with simple SQL, it does do locking and
> >> consistent operations thanks to the postgresql infrastructure wrapped
> >> around it.
> >>
> >> As an architect my recommendation would be: since the development
> >> overhead in building your system from scratch will be quite high,
> >> investing the time into a load test on PostGIS first could save you a
> >> lot of time if it turns out that even our imperfect system is actually
> >> good enough to meet your needs.
> >>
> >> Best,
> >>
> >> P.
> >> _______________________________________________
> >> postgis-users mailing list
> >>
> >> postgis-users at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users




More information about the postgis-users mailing list