So I might have understood an earlier description of the proposed
solution all wrong, or this patch was designed without consideration to
that description. What I thought would happen is that all freeze ages
would get multiplied by some factor <= 1, depending on the space used up
by members. If members space usage is low enough, factor would remain
at 1 so things would behave as today. If members space usage is larger
than X, the factor decreases smoothly and this makes freeze_min_age and
freeze_max_age decrease smoothly as well, for all vacuums equally.
For instance, we could choose a method to compute X based on considering
that a full 2^32 storage area for members is enough to store one
vacuum_multixact_freeze_table_age cycle of multixacts. The default
value of this param is 150 million, and 2^32/150000000 = 28; so if your
average multixact size = 38, you would set the multiplier at 0.736 and
your effective freeze_table_age would become 110 million and effective
freeze_min_age would become 3.68 million.
As a secondary point, I find variable-names-as-documentation bad
practice. Please don't use a long name such as
max_multixact_age_to_avoid_member_wrap; code becomes unwieldy. A short
name such as safe_mxact_age preceded by a comment /* this variable is
the max that avoids member wrap */ seems more palatable; side-by-side
merges and all that! I don't think long function names are as
problematic (though the name of your new function is still a bit too
long).
Please note that 9.4 and earlier do not have ExecVacuum; the
determination of freeze ages is done partly in gram.y (yuck). Not sure
what will the patch look like in those branches.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services