From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_multixact not getting truncated |
Date: | 2014-11-10 04:00:58 |
Message-ID: | 5460387A.1040907@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/08/2014 01:46 PM, Andres Freund wrote:
> I think it'd be a good idea to tune them more automatedly in the
> future. But I think the current situation where you can vastly increase
> multivacuum_freeze_max_age while having
> multivacuum_multixact_freeze_max_age is *much* more useful in practice
> than when they always were the same.
Can you explain that? Because I'm not picturing the situation where
that would make sense.
>> I'm still not convinced that it makes sense to have a separate multixact
>> threshold at all **since the same amount of vacuuming needs to be done
>> regardless of whether we're truncating xids or mxids**.
>
> That's just plain wrong. The growth rate of one can be nearly
> independent of the other. It can e.g. be very sensible to have a huge
> xid freeze limit, but a much smaller multixact limit.
Yah, so who cares? Either way you're in for a full table scan, and if
you're doing the full table scan anyway, you might as well freeze the xids.
>> Certainly when I play with tuning this for customers, I'm going to lower
>> vacuum_freeze_table_age as well.
>
> I'm these days suggesting that people should add manual vacuuming for
> "older" relations during off peak hours on busy databases. There's too
> many sites which service degrades noticeably during a full table vacuum.
Me too: https://github.com/pgexperts/flexible-freeze
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-11-10 04:48:28 | Re: Doing better at HINTing an appropriate column within errorMissingColumn() |
Previous Message | Peter Geoghegan | 2014-11-10 03:31:08 | Compiler warning in master branch |