Message-ID: <4d67ed07-bc37-ac42-3ea6-bcce1db5a38e@amazon.com>
Date: Thu, 25 Aug 2022 15:35:17 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.0
Subject: Re: New strategies for freezing, advancing relfrozenxid early
Content-Language: en-US
To: Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers
	<pgsql-hackers@lists.postgresql.org>
References: 
 <CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3J0AAd6FXk93u-Xq3Fg@mail.gmail.com>
From: Jeremy Schneider <schnjere@amazon.com>
In-Reply-To: 
 <CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3J0AAd6FXk93u-Xq3Fg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/4d67ed07-bc37-ac42-3ea6-bcce1db5a38e%40amazon.com>
Precedence: bulk

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