Robert Haas <robertmhaas@gmail.com> wrote:
> 1. Using a min freeze age of zero will result in half as many
> full-table scans, because we'll advance relminmxid twice as far
> each time.
>
> 2. But each one will freeze more stuff, some of which might have
> been updated again before the next freeze pass, so we might do
> more freezing in total.
>
> So either policy might win, depending on whether you care more
> about reducing reads (in which case you want a very low min
> freeze age) or about reducing writes (in which case you want a
> higher min freeze age).
>
> All things being equal, I'd rather stick with the existing 50%
> policy in the back-branches, rather than going to zero, but I'm
> not sure all things are equal. It matters what difference the
> higher value makes.
I really don't like the "honor the configured value of
vacuum_multixact_freeze_min_age until the members SLRU gets to 50%
of wraparound and then use zero" approach. It made a lot more
sense to me to honor the configured value to 25% and decrease it in
a linear fashion until it hit zero at 75%. It seems like maybe we
weren't aggressive enough in the dynamic adjustment of
autovacuum_multixact_freeze_max_age, but I'm not clear why fixing
that required the less gradual adjustment of the *_min_age setting.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
