Received: from master.phlo.org (master.phlo.org [213.147.174.89]) by developer.postgresql.org (Postfix) with ESMTP id D47422E01D1 for ; Fri, 30 May 2008 11:09:19 -0300 (ADT) Received: (qmail 5303 invoked by uid 0); 30 May 2008 08:42:35 -0000 Received: from chello080109034055.10.14.vie.surfer.at (HELO phlook.local) (fgp@[80.109.34.55]) (envelope-sender ) by imap.phlo.org (qmail-ldap-1.03) with SMTP for ; 30 May 2008 08:42:35 -0000 Message-ID: <483FBDFA.4090401@phlo.org> Date: Fri, 30 May 2008 10:42:34 +0200 From: "Florian G. Pflug" User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Kevin Grittner CC: Simon Riggs , pgsql-hackers Subject: Re: Hint Bits and Write I/O References: <1211916951.4489.232.camel@ebony.site> <483C7CE8.2090404@phlo.org> <1211926242.4489.301.camel@ebony.site><1211926242.4489.301.camel@ebony.site> <483DEA2D.3010704@phlo.org> <483EE689.EE98.0025.0@wicourts.gov> In-Reply-To: <483EE689.EE98.0025.0@wicourts.gov> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archive-Number: 200805/1035 X-Sequence-Number: 119034 Kevin Grittner wrote: >>>> On Wed, May 28, 2008 at 6:26 PM, in message > <483DEA2D.3010704@phlo.org>, > "Florian G. Pflug" wrote: > >> I think we should put some randomness into the decision, >> to spread the IO caused by hit-bit updates after a batch load. > > Currently we have a policy of doing a VACUUM FREEZE ANALYZE on a table > after a bulk load, or on the entire database after loading a pg_dump > of a database. We do this before putting the table or database into > production. This avoids surprising clusters of writes at > unpredictable times. Please don't defeat that. (I'm not sure whether > your current suggestion would.) No, VACUUM (and therefore VACUUM FREEZE) dirty all buffers they set hit bits on anyway, since they also update the xmin values. But a more IO-friendly approach to setting hit bits might make that VACUUM FREEZE step unnecessary ;-) regards, Florian Pflug