From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Default setting for autovacuum_freeze_max_age |
Date: | 2016-10-26 19:46:14 |
Message-ID: | CAEepm=2FS0E9rvvv7oGYw9opC-wDBP1gkVA8JCNwQg-UxZXz3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 27, 2016 at 6:55 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 10/21/2016 10:29 AM, Robert Haas wrote:
>> On Fri, Oct 21, 2016 at 1:17 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>> Particularly, with 9.6's freeze map, point (2) is even stronger reason
>>> to *lower* autovacuum_max_freeze_age. Since there's little duplicate
>>> work in a freeze scan, a lot of users will find that frequent freezing
>>> benefits them a lot ...
>>
>> That's a very good point, although I hope that vacuum is mostly being
>> triggered by vacuum_freeze_table_age rather than
>> autovacuum_freeze_max_age.
>
> Well, depends on the nature of writes to the table. For insert-mostly
> tables, vacuum_freeze_table_age is pretty much never triggered. Isn't
> there a patch for that somewhere?
>
>>
>> On Bruce's original question, there is an answer written into our
>> documentation: "Vacuum also allows removal of old files from the
>> pg_clog subdirectory, which is why the default is a relatively low 200
>> million transactions."
>
> Point.
It also affects pg_commit_ts size (if enabled), and it uses 40x more
space per xid than pg_clog if I've read the code right. I have
wondered before[1] if we should document that.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2016-10-26 19:54:22 | Re: pg_hba_file_settings view patch |
Previous Message | Merlin Moncure | 2016-10-26 19:25:10 | Re: emergency outage requiring database restart |