Re: Visibility map and freezing

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: Visibility map and freezing
Date: 2009-01-22 19:04:45
Message-ID: 4978C34D.3050208@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2009-01-22 19:09:35 Re: Table Partitioning Feature
Previous Message Heikki Linnakangas 2009-01-22 18:36:06 Re: problem with archive_command as suggested by documentation