[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