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 frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
