[OSM-dev] slow diff updates / FASTUPDATE / osm2pgsql bug

Frederik Ramm frederik at remote.org
Sun Aug 7 20:19:12 BST 2011


Hi,

Sven Geggus wrote:
> Removing the double negative here this will read as:
> "If you are using standard index tablespaces"

Yes, that's what I said ;)

> I supose this bug is the cause for the problems many people
> (including myself) where talking abount on this list in the last few
> months.

I became suspicious when a system of mine had slow updates but it wasn't 
disk-bound at all. What you expect to see during a diff update on 
anything but the fastest mega-SSD boxes is that one CPU is in I/O wait 
most of the time, which wasn't the case on my box - updates were taking 
long but only a small portion of that time was spent with I/O.

To be a bit clearer on the procedure to fix things: Either re-import, or 
re-create indexes with

DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;

CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING gin (nodes) 
WITH (fastupdate=off);

CREATE INDEX planet_osm_rels_parts ON planet_osm_rels USING gin (parts) 
WITH (fastupdate=off);

This will take a while but it is possible to do that without much 
adverse effect on rendering (i.e. the DB will slow down because it 
re-generates the index but these indexes are not used for rendering). 
Don't attempt to apply a diff update without these indexes in place.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"



More information about the dev mailing list