Re: Visibility map and freezing - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Visibility map and freezing
Date
Msg-id 4978C34D.3050208@enterprisedb.com
Whole thread Raw
In response to Re: Visibility map and freezing  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: problem with archive_command as suggested by documentation
Next
From: Josh Berkus
Date:
Subject: Re: Table Partitioning Feature