Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 1F9041337B8A for ; Tue, 8 Feb 2011 05:10:30 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 11177-03 for ; Tue, 8 Feb 2011 09:10:23 +0000 (UTC) X-Greylist: delayed 00:29:08.593168 by SQLgrey-1.7.6 Received: from alibaba2.comgate.cz (mail3.comgate.cz [78.102.13.243]) by mail.postgresql.org (Postfix) with ESMTP id CDA981337B83 for ; Tue, 8 Feb 2011 05:10:22 -0400 (AST) Received: from [10.1.1.60] (unknown [10.1.0.172]) by alibaba2.comgate.cz (ComGateMailGW) with ESMTP id 888F8EE4024; Tue, 8 Feb 2011 09:41:12 +0100 (CET) Message-ID: <4D5101A8.10503@comgate.cz> Date: Tue, 08 Feb 2011 09:41:12 +0100 From: Jakub Ouhrabka User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; cs; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: pgsql-performance@postgresql.org, josh@agliodbs.com Subject: Re: Write-heavy pg_stats_collector on mostly idle server References: <4D4C4E15.20401@agliodbs.com> <4D507920.2030909@agliodbs.com> <1297120356.18411.197.camel@jd-desktop> <4D509EE1.4070305@agliodbs.com> In-Reply-To: <4D509EE1.4070305@agliodbs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/300 X-Sequence-Number: 42438 Hi Josh, it's "known" issue, see this thread: http://archives.postgresql.org/pgsql-hackers/2010-02/thrd6.php#01290 HTH, Kuba Dne 8.2.2011 2:39, Josh Berkus napsal(a): > >> Ooops. >> It looks like you are right, see ./src/backend/postmaster/pgstat.c >> >> 3c2313f4 (Tom Lane 2008-11-03 01:17:08 +0000 2926) >> if (last_statwrite< last_statrequest) >> 70d75697 (Magnus Hagander 2008-08-05 12:09:30 +0000 2927) >> pgstat_write_statsfile(false); > > This is a different issue. This is happening because we have a bunch of > databases (25 to 35) and as a result autovacuum is requesting the stats > file rather frequently. And autovacuum for whatever reason won't accept > a stats file more than 10ms old, so it pretty much rewrites the stats > file on every request. > > At least, that's my reading of it after poking around and talking to > Gierth. > > It seems like that 10ms window for autovac is way too small. >