Re: Hint Bits and Write I/O

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hint Bits and Write I/O
Date: 2008-05-30 08:42:34
Message-ID: 483FBDFA.4090401@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Kevin Grittner wrote:
>>>> On Wed, May 28, 2008 at 6:26 PM, in message
> <483DEA2D(dot)3010704(at)phlo(dot)org>,
> "Florian G. Pflug" <fgp(at)phlo(dot)org> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2008-05-30 08:52:36 Re: Avoiding second heap scan in VACUUM
Previous Message Dimitri Fontaine 2008-05-30 08:29:30 Re: Core team statement on replication in PostgreSQL

Browse pgsql-patches by date

  From Date Subject
Next Message Teodor Sigaev 2008-05-30 10:08:05 GIN improvements
Previous Message KaiGai Kohei 2008-05-30 06:08:56 Re: [0/4] Proposal of SE-PostgreSQL patches