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

[Howard Butler]

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