From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: postgresql@taljaren.se, pgsql-bugs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
Subject: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
Date: Fri, 16 Dec 2022 15:33:33 -0500
Message-ID: <3843992.1671222813@sss.pgh.pa.us> (raw)
In-Reply-To: <CAH2-WzkHRxcE-0Mub9N0Rr09SGEEF1Ex4pUbcOBSRoNGNVy93w@mail.gmail.com>
References: <17717-6c50eb1c7d23a886@postgresql.org>
<3439037.1671130590@sss.pgh.pa.us>
<CAH2-Wzne4Wgaaruq-VSY2qWNhxcPRqWUbdwVQPkM81TpaHY_kQ@mail.gmail.com>
<3544447.1671141436@sss.pgh.pa.us>
<CAH2-WzkXmYt-K+pQqMqjFgwU7jiykD3amngd5-jkqQF=gST7Og@mail.gmail.com>
<3672943.1671202149@sss.pgh.pa.us>
<CAH2-WzkHRxcE-0Mub9N0Rr09SGEEF1Ex4pUbcOBSRoNGNVy93w@mail.gmail.com>
Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Dec 16, 2022 at 6:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That is a really good point. How about teaching VACUUM to track
>> the oldest original relfrozenxid and relminmxid among the table(s)
>> it processed, and skip vac_update_datfrozenxid unless at least one
>> of those matches the database's values? For extra credit, also
>> skip if we didn't successfully advance the source rel's value.
> Hmm. I think that that would probably work.
> It would certainly work on 15+, because there tends to be "natural
> diversity" among the relfrozenxid values seen for each table, due to
> the "track oldest extant XID" work; we no longer see many tables that
> all have the same relfrozenxid, that advance in lockstep. But even
> that factor probably doesn't matter, since we only need one "laggard
> relfrozenxid" static table for the scheme to work and work well. That
> is probably a safe bet on all versions, though I'd have to check to be
> sure.
Oh, I see your point: if a whole lot of tables have the same relfrozenxid
and it matches datfrozenxid, this won't help. Still, we can hope that
that's an uncommon situation. If we postulate somebody trying to use
scheduled "vacuumdb -z" in place of autovacuum, they shouldn't really have
that situation. Successively vacuuming many tables should normally
result in the tables' relfrozenxids not being all the same, unless they
were unlucky enough to have a very long-running transaction holding back
the global xmin horizon the whole time.
regards, tom lane
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: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, pg@bowt.ie, michael@paquier.xyz
Subject: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
In-Reply-To: <3843992.1671222813@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox