public inbox for [email protected]
help / color / mirror / Atom feedFrom: wenhui qiu <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: [email protected]
Subject: Re: another autovacuum scheduling thread
Date: Thu, 30 Oct 2025 10:58:44 +0800
Message-ID: <CAGjGUAJ-XqLN6VU+HeXn0iooiJrrnN4Pqp+xVU8VKKNsZcfR2w@mail.gmail.com> (raw)
In-Reply-To: <aQI7tGEs8IOPxG64@nathan>
References: <CAApHDvp1=FOs6GneTzLSCHnCmC7z1_80=U3M=CKd82-pwS3YHg@mail.gmail.com>
<aPuWev3D9M4iGCUt@nathan>
<CAApHDvoM5MEHHBc0TNdrzkpq39WdEHSZhdWrtnx9zOWNXTSFGw@mail.gmail.com>
<aP-YgrcPi0EhgR9x@nathan>
<CAA5RZ0u2Mbks+O2DKBYen94AH3OMUcg+A7wvxrXYkmjTddBx4g@mail.gmail.com>
<aP_g61kSkGAQOu3F@nathan>
<CAA5RZ0sybfRyKp+DY+r=2U+-r7HfSF4GL1oVOOcVtEWmk2ewUw@mail.gmail.com>
<CAApHDvpVE5F-_8rpPC+-L98mA0yK0S_jtQGqLn69fkRevf726g@mail.gmail.com>
<aQEwRD5XW4wfJE6G@nathan>
<CAA5RZ0uGbpaom3v+2K=bNuitnSGX_Lw4yPj3SbJdABYKgGur_A@mail.gmail.com>
<aQI7tGEs8IOPxG64@nathan>
HI Nathan
> That approach would begin aggressively scaling the priority of tables
> sooner, but I don't know if that's strictly better. In any case, I'd like
> to avoid making the score calculation too magical.
In fact, with the introduction of the vacuum_max_eager_freeze_failure_rate
feature, if a table’s age still exceeds more than 1.x times the
autovacuum_freeze_max_age, it suggests that the vacuum freeze process is
not functioning properly. Once the age surpasses vacuum_failsafe_age,
wraparound issues are likely to occur soon.Taking the average of
vacuum_failsafe_age and autovacuum_freeze_max_age is not a complex
approach. Under the default configuration, this average already exceeds
four times the autovacuum_freeze_max_age. At that stage, a DBA should have
already intervened to investigate and resolve why the table age is not
decreasing.
Thanks
On Thu, Oct 30, 2025 at 12:07 AM Nathan Bossart <[email protected]>
wrote:
> On Wed, Oct 29, 2025 at 10:24:17AM -0500, Sami Imseih wrote:
> > I think we do need some documentation about this behavior, which v6 is
> > still missing.
>
> Would you be interested in giving that part a try?
>
> > Another thing I have been contemplating about is the change in
> prioritization
> > and the resulting difference in the order in which tables are vacuumed
> > is what it means for workloads in which autovacuum tuning that was
> > done with the current assumptions will no longer be beneficial.
> >
> > Let's imagine staging tables that get created and dropped during
> > some batch processing window and they see huge data
> > ingestion/changes. The current scan will make these less of a priority
> > naturally in relation to other permanent tables, but with the new
> priority,
> > we are making these staging tables more of a priority. Users will now
> > need to maybe turn off autovacuum on a per-table level to prevent this
> > scenario. That is just one example.
> >
> > What I am also trying to say is should we provide a way, I hate
> > to say a GUC, for users to go back to the old behavior? or am I
> > overstating the risk here?
>
> It's probably worth testing out this scenario, but I can't say I'm terribly
> worried. Those kinds of tables are already getting chosen by autovacuum
> earlier due to reltuples == -1, and this patch will just move them to the
> front of the list that autovacuum creates. In any case, I'd really like to
> avoid a GUC or fallback switch here.
>
> --
> nathan
>
>
>
view thread (143+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: another autovacuum scheduling thread
In-Reply-To: <CAGjGUAJ-XqLN6VU+HeXn0iooiJrrnN4Pqp+xVU8VKKNsZcfR2w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox