Heikki Linnakangas wrote:
ITAGAKI Takahiro wrote:
- What relation are there between autovacuum_freeze_max_age,
vacuum_freeze_min_age and vacuum_freeze_table_age? If we increase
one of them, should we also increase the others?
Yeah, that's a fair question. I'll try to work a doc patch to explain
that better.
Ok, how does this sound:
<para>
+ <command>VACUUM</> normally skips pages that don't have any dead row
+ versions, but those pages might still have tuples with old XID values.
+ To replace them too, a scan of the whole table is needed every once
+ in a while. <varname>vacuum_freeze_table_age</> controls when
+ <command>VACUUM</> does that: a whole table sweep is forced if
+ <structfield>relfrozenxid</> is more than
+ <varname>vacuum_freeze_table_age</> transactions old. Setting it to 0
+ makes <command>VACUUM</> to ignore the visibility map and always
scan all
+ pages. The effective maximum is 0.95 *
<varname>autovacuum_freeze_max_age</>;
+ a setting higher than that will be capped to that maximum. A value
+ higher than <varname>autovacuum_freeze_max_age</> wouldn't make sense
+ because an anti-wraparound autovacuum would be triggered at that point
+ anyway, and the 0.95 multiplier leaves some breathing room to run a
manual
+ <command>VACUUM</> before that happens. As a rule of thumb,
+ <command>vacuum_freeze_table_age</> should be set to a value somewhat
+ below <varname>autovacuum_freeze_max_age</>. Setting it too close could
+ lead to anti-wraparound autovacuums, even though the table was recently
+ manually vacuumed, whereas lower values lead to more frequent
whole-table
+ scans.
+ </para>
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
