[OSM-dev] mysql partitioning

[Nick Hill]

Hello Andreas

I agree, in conjunction with changing lat/lon co-ords to integers, the 
index look-ups based on lat/lon can be improved perhaps by at least an 
order of magnitude. By partitioning on longitude, I can imagine those 
indexes automatically being loaded into and out of memory depending on 
activity - day or night in the area.

I have held up doing anything on this whilst Steve puts the API on rails.

Steve- do you think it reasonable to add a superset of the current API 
to the API 0.4 where the query and return values are integers for lat/lon?

However, most of the database time seems to be spent pulling segments 
from the database. For every node in the selected area, an index look-up 
is performed for segments associated with that node. Then for segments 
which have only one node associated with them, the other node is 
downloaded. This is very, very db intensive.

A dirty (because it will result in data duplication) hack would be to 
attach a lat/lon to segments and ways. This can be hidden behind the API.

Andreas Brauchli wrote:
> i've seen following news on mysql.com somewhen last week and think that
> it could potentially provide a useful speedup to OSM.
> 
> http://dev.mysql.com/tech-resources/articles/performance-partitioning.html
> 
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>