MIME-Version: 1.0
References: <2be31f17-5405-4de9-8d73-90ebc322f7d8@vondra.me>
 <CAAKRu_Ypa7-JGVR+fstDxU5Cfitk_rf5ijdaqwtoPkztursufA@mail.gmail.com>
 <CAAKRu_ZrDadxmGepBwPZ03yAKnMxwsHYn8SK9Gg7VqigLLVUWg@mail.gmail.com>
 <CAApHDvqAOeOwCKh9g0gfxWa040=Hyc7_oA=C59rjod8kXJDWyw@mail.gmail.com>
 <CAAKRu_Yt76_HdfR6DtK_wtkSNSj9=VxSV_npt+6T2R=zTzp1Pg@mail.gmail.com>
 <CAAKRu_atv6zA274m8Ysgbfn49c0NbdvHT7nXvd9kroZKnFq8Dg@mail.gmail.com>
 <CAApHDvq_R-gNXu+06GQW6w_HaEMh1pezsyiCh7GNhgh+h0UqMw@mail.gmail.com>
 <CAAKRu_YfoGTHNn0XxA+dCPj9hyO96vO4Eb+awRR6T8m22qC6ww@mail.gmail.com>
 <97529f5a-ec10-46b1-ab50-4653126c6889@gmail.com>
 <CAAKRu_b=X-P26hB96i2vG40PhJB_5L=ARuNHV4SJngMPap8H3A@mail.gmail.com>
 <yemtvnnnj4c6ehsmv6cu2x7h5i3nentpoeuqdtmyp3lnrw7ydu@7uwd2pogt5nv>
In-Reply-To: <yemtvnnnj4c6ehsmv6cu2x7h5i3nentpoeuqdtmyp3lnrw7ydu@7uwd2pogt5nv>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Thu, 16 Apr 2026 16:21:35 -0400
Message-ID: 
 <CAAKRu_a_t6yHc94K6WkjUg_bDgXSK33LAYNACZFg-3RjrPPMcw@mail.gmail.com>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
To: Andres Freund <andres@anarazel.de>
Cc: Alexander Lakhin <exclusion@gmail.com>, Tomas Vondra <tomas@vondra.me>,
	David Rowley <dgrowleyml@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>,
	Chao Li <li.evan.chao@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>,
	Xuneng Zhou <xunengzhou@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAAKRu_a_t6yHc94K6WkjUg_bDgXSK33LAYNACZFg-3RjrPPMcw%40mail.gmail.com>
Precedence: bulk

On Sun, Apr 5, 2026 at 11:49=E2=80=AFAM Andres Freund <andres@anarazel.de> =
wrote:
>
> I think we should probably just have GetLocalPinLimit() return something
> considerably smaller than num_temp_buffers, e.g. num_temp_buffers / 4 or
> so.

I think num_temp_buffers / 4 seems reasonable for GetLocalPinLimit().
We'd also need to make this change in GetAdditionalLocalPinLimit().

Making this change fixes the specific case Alexander pointed out.

We will likely see an impact on performance impact because this will
keep the readahead distance substantially lower for temp table cases
with only one read stream.

> There always may be more than one scan going on, so we can't ever promise=
 that
> there's at least a certain number of pins available. The main goal of the
> shared pin limit is to prevent one backend from pinning disproportionally=
 much
> of s_b.  And for that eventually scaling down to just needing 1-2 pins pe=
r
> scan is sufficient.

With the last sentence "And for that eventually scaling down to just
needing 1-2 pins per scan is sufficient." -- how do you mean to relate
that to what we will do with local buffers case?

- Melanie