Alvaro Herrera wrote:
> 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.
Actually, apologies --- this is not what I was thinking at all. I got
distracted while I was writing the previous email. My thinking was that
the values would be at their normal defaults when the wraparound is
distant, and the multiplier would start to become slightly less than 1
as the counter moves towards wraparound; by the time we're at at an
emergency i.e. we reach max_freeze_age, the values naturally become zero
(or perhaps just before we reach max_freeze_age, the values were 50% of
their normal values, so the drop to zero is not as dramatic). Since
this is gradual, the behavior is not as jumpy as in the proposed patch.
Anyway this is in line with what Kevin is saying elsewhere: we shouldn't
just use the normal values all the time just up to the freeze_max_age
point; there should be some gradual ramp-up.
Perhaps we can combine this with the other idea of using a multiplier
connected to average size of multixact, if it doesn't become too
complicated, surprising, or both.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services