Hi, some final results: I monitored the vaccum process and logged some data using one big table and doing analyze/vaccum by hand. Table has two btree-indexes and one gin. maintenance_work_mem was 1GB. the analyze job used abot 1.2 GB virt mem during the whole task, no problems at all. The vacuum josb started with 3.3 GB and after processing the two "simple" indexes it used up to 5.5 GB of Vmem going down to 2.3 GB for the final work. <http://postgresql.nabble.com/file/n5840914/pidstat.png> This lead to out of memory problems during the last days. The vacuum of the first table (planet_osm_ways) used *upto 12 GB* until the OOM-Killer killed him. Sorry, but *why do analyze and vacuum ignore maintenance_work_mem?* I have no control about memory usage and ran in big trouble. Now i added 50GB swap to my 24GB system and have to cross my fingers. regards walter -- View this message in context: http://postgresql.nabble.com/autovacuum-worker-running-amok-and-me-too-tp5840299p5840914.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
