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
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 |
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 |