[OSM-dev] Lite OSM backend

Nicola Ranaldo ranaldo at unina.it
Tue Sep 12 11:48:46 BST 2006


On Sunday 10 September 2006 01:25, Nick Hill wrote:
> Hello Niko
>
> I have performed tests on node data types under R-tree indexes with
> simulated load as well as B-tree.
>
> The R-tree index implementation which I tried for node data type caused
> a large number of  page faults requiring big disc seeks. From my tests,
> I predict B-tree segmented indexes will give the overall best
> performance for point/node data types.
>
> I would like to see a move towards an R-tree index and spatial data
> types for polygons to make polygon inheritance possible/efficient.

I tested for a a bit the cluster option with postgresql on 
node/segment/segmenttoway tables all with a replicated "box" field indexed as 
rtree., the query speedups is very high about index seeking  and a bit faster 
in data retrieval.I did not find yet a method to specify the twodimensional 
factor to reorder the table on a well specified tile to optimize queries. 
Howewer while "clustering", the table is locked and no other query is 
possibile. The operation itself is  quite long so it's not applicable to a 
production server. The second problem is that the table are not really 
clustered, but the operation finalizes in a physical reordering of the 
cluster table, every insert or update of data are not handled automatically, 
so cluster operation should be lauched periodically.  Due to this 
considerations it seems better to write the customized backend we are 
speaking about, or to rearrange some other solutions. For example a nice idea 
could be in adopting a berkeley db with the key as quadtree and values as a 
bitcompacted tile rappresentation adapting the area size dinamically (the 
same could be done server-side on a sql backend).

About page faults on r-tree indexes, it may be they spawn on more pages than 
two monodimensional indexes, so they may be expensive in the initial loading, 
but may speedup a lot when are cached.

	Niko

 




More information about the dev mailing list