[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