Paul Norman wrote > Indexes aren't vacuumed, tables are. Are you vacuuming the table or > rebuilding theindex?
autovacuum vacuumed planet_osm_ways, but when this comes to the gin-index it starts growing. Saw this during same tests running yesterday. <http://gis.19327.n5.nabble.com/file/n5836445/pidstat.png> scale left is in MB. at 2:25 it starts using the gin-index planet_osm_ways_nodes. > If you have autovacuum tuned aggressively enough there should be no > need to manually vacuum the slim tables. The GIN indexes do tend to > bloat, and this can be fixed by stopping updates, dropping the old > index and building a new one. just doing it - recreating index. fyi: it's about 133GB big and needs more then 10 hours to recreate it. > If you have autovacuum tuned aggressively enough there should be no > need to manually vacuum the slim tables. is that the reason? doing not enough vacuums so that this one is too big and that is making problems? but *why is vacuum ignoring maintenance_work_men* and bringing my system to thashing? I think, THAT is the real problem - and we from osm can't fix it :( 6 more hours to wait for the index, database offline to users, diff-import stopped for 35 hours. i'v had better days. Regards walter ----- [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0.2[/url] -- View this message in context: http://gis.19327.n5.nabble.com/vacuum-running-amok-and-me-too-tp5836373p5836445.html Sent from the Developer Discussion mailing list archive at Nabble.com. _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
