Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TWrB1-0004D4-Tv for pgsql-admin@postgresql.org; Fri, 09 Nov 2012 16:11:28 +0000 Received: from mailout-us.gmx.com ([74.208.5.67]) by makus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TWrB0-0000y2-BK for pgsql-admin@postgresql.org; Fri, 09 Nov 2012 16:11:27 +0000 Received: (qmail 446 invoked by uid 0); 9 Nov 2012 15:59:59 -0000 Received: from 76.255.19.161 by rms-us009 with HTTP Cc: cedric@2ndquadrant.com Content-Type: text/plain; charset="utf-8" Date: Fri, 09 Nov 2012 10:59:57 -0500 From: "Kevin Grittner" Message-ID: <20121109155957.77890@gmx.com> MIME-Version: 1.0 Subject: Re: Autoanalyze of the autovacuum daemon ... To: "Baptiste LHOSTE" ,pgsql-admin@postgresql.org X-Authenticated: #138763884 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: Kk3vcAl/3zOlOQ09LnwhKtJ+IGRvb4AZ X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201211/60 X-Sequence-Number: 40305 Baptiste LHOSTE wrote: >> Please show us the output from running this query: >> >> http://wiki.postgresql.org/wiki/Server_Configuration > [very reasonable settings except for a very large work_mem] Make sure that work_mem setting isn't driving you into swapping or near-zero caching. A shortage of cache space could explain this because it looks like about 8.5 ms for each page read. About the only other thing I can think to recommend is to decrease autovacuum_cost_delay to 10ms and see if that helps. > These tables have two timestamp columns and a btree index on both > timestamp column. Will it be more efficient for us to configure the > autovacuum daemon analyze task only on those columns ? No. > 4 * 300 Go Raid 0 You do realize that if any of those four drives fail you will need to use your backup, right? -Kevin