From: Jeremy Schneider <schnjere@amazon.com>
To: Peter Geoghegan <pg@bowt.ie>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: New strategies for freezing, advancing relfrozenxid early
Date: Thu, 25 Aug 2022 15:35:17 -0700
Message-ID: <4d67ed07-bc37-ac42-3ea6-bcce1db5a38e@amazon.com> (raw)
In-Reply-To: <CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3J0AAd6FXk93u-Xq3Fg@mail.gmail.com>
References: <CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3J0AAd6FXk93u-Xq3Fg@mail.gmail.com>
On 8/25/22 2:21 PM, Peter Geoghegan wrote:
>
> New patch to avoid allocating MultiXacts
> ========================================
>
> The fourth and final patch is also new. It corrects an undesirable
> consequence of the work done by the earlier patches: it makes VACUUM
> avoid allocating new MultiXactIds (unless it's fundamentally
> impossible, like in a VACUUM FREEZE). With just the first 3 patches
> applied, VACUUM will naively process xmax using a cutoff XID that
> comes from OldestXmin (and not FreezeLimit, which is how it works on
> HEAD). But with the fourth patch in place VACUUM applies an XID cutoff
> of either OldestXmin or FreezeLimit selectively, based on the costs
> and benefits for any given xmax.
>
> Just like in lazy_scan_noprune, the low level xmax-freezing code can
> pick and choose as it goes, within certain reasonable constraints. We
> must accept an older final relfrozenxid/relminmxid value for the rel's
> authoritative pg_class tuple as a consequence of avoiding xmax
> processing, of course, but that shouldn't matter at all (it's
> definitely better than the alternative).
We should be careful here. IIUC, the current autovac behavior helps
bound the "spread" or range of active multixact IDs in the system, which
directly determines the number of distinct pages that contain those
multixacts. If the proposed change herein causes the spread/range of
MXIDs to significantly increase, then it will increase the number of
blocks and increase the probability of thrashing on the SLRUs for these
data structures. There may be another separate thread or two about
issues with SLRUs already?
-Jeremy
PS. see also
https://www.postgresql.org/message-id/247e3ce4-ae81-d6ad-f54d-7d3e0409a950@ardentperf.com
--
Jeremy Schneider
Database Engineer
Amazon Web Services
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-hackers@postgresql.org
Cc: schnjere@amazon.com, pg@bowt.ie, pgsql-hackers@lists.postgresql.org
Subject: Re: New strategies for freezing, advancing relfrozenxid early
In-Reply-To: <4d67ed07-bc37-ac42-3ea6-bcce1db5a38e@amazon.com>
* 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