Re: mxid_score can become Infinity in pg_stat_autovacuum_scores - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: mxid_score can become Infinity in pg_stat_autovacuum_scores
Date
Msg-id CAA5RZ0tTJkFPA0=Wqs5hBLLA=h=F340VJok2PLTv3kZ4rL3C7w@mail.gmail.com
Whole thread
Responses Re: mxid_score can become Infinity in pg_stat_autovacuum_scores
List pgsql-hackers
> > I do think we need to mention in the docs also about this caveat
> > in scoring, so users of pg_stat_autovacuum_scores are not surprised.
> > As member space usage grows between 2 billion and 4 billion, the
> > score ramps up gradually, but once members reach 4 billion the effective freeze
> > max age drops to 0 and the score jumps to mxid_age itself,
> > which could be in the hundreds of millions.
>
> I'm -0.2 for documenting this case.  I understand that users might be
> confused about the results in such extreme situations, but I worry more
> about users being confused by the excruciating detail of the documentation.
> The existing docs are already quite complex, but I did spent a lot of time
> trying to find the right balance of detail and accessibility when
> committing.

I think this particular scenario is very clear to explain just like
how we explain
the failsafe scenario. Also, the suggested docs in the view link to the already
existing detailed explanation of this behavior.

More generally, I think anytime there is a drastic change in a score, like
jumping from a gradually ramping value around 1.x to suddenly hundreds of
millions, that's something worth calling out in the docs. Users monitoring
pg_stat_autovacuum_scores will notice that jump and want to understand why
it happened.

--
Sami Imseih
Amazon Web Services (AWS)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Direction for test frameworks: Perl TAP vs. Python/pytest
Next
From: Corey Huinker
Date:
Subject: Re: Fix --missing-stats-only false positive for partitioned expression indexes