Kevin Grittner wrote:
On Wed, May 28, 2008 at 6:26 PM, in message
<[EMAIL PROTECTED]>,
"Florian G. Pflug" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
