Re: The case against multixact GUCs

Sigh ...

Josh Berkus wrote:

> Further, there's no clear justification why these cannot be set to be
> the same as our other freeze ages (which our users also don't
> understand), or a constant calculated portion of them, or just a
> constant.

Calculated portion was my first proposal. The objection that was raised
was that there's no actual correlation between Xid consumption rate and
multixact consumption rate. That observation is correct; in some use
cases multixacts will be consumed faster, in others they will be
consumed slower. So there's no way to have multixact cleanup not cause
extra autovacuum load if we don't have the parameters.

> Since nobody anticipated someone adding a GUC in a minor
> release, there was no discussion of this topic that I can find; the new
> GUCs were added as a "side effect" of fixing the multixact vacuum issue.
> Certainly I would have raised a red flag if the discussion of the new
> GUCs hadn't been buried deep inside really long emails.

When problems are tough, explanations get long. There's no way around
that. I cannot go highlighting text in red hoping that people will read
those parts.

> Adding new GUCs which nobody has any idea how to set, or can even
> explain to new users, is not a service to our users. These should be
> removed.

I don't think we're going to remove the parameters. My interpretation
of the paragraph above is "can we please have some documentation that
explains how to set these parameters". To that, the answer is sure, we
can. However, I don't have time to write it at this point.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services