MIME-Version: 1.0
References: <issqornf6vdn3vb64fjuoathypmu3e5pgputd3lpfuvoeqyvzr@qfordnhplp2v>
 <CAE8JnxOn4+xUAnce+M7LfZWOqfrMMxasMaEmSKwiKbQtZr65uA@mail.gmail.com>
 <7e707787-272a-4c52-b5f1-5ac990514ecc@vondra.me>
 <c96ba898-02fb-4756-a1c7-0ddb08159804@vondra.me>
 <CAE8JnxPtia9m8y7b5s+gOMjZ_3QP=pTo+A6p_HmtrAV4PMo3ZQ@mail.gmail.com>
 <e972a7ab-015c-4026-8ef7-5a49f59f10f8@vondra.me>
 <CAE8JnxOJ48NU3rwW+gS67NUDKgxDS5pKNUywbUBGCBJkgUf+Hg@mail.gmail.com>
 <bf66ffb5-74b7-433d-aee4-0c9f29f97324@vondra.me>
 <3cbwjhwkomjv7jifau4yhb357gfnckut3sdrlbmhwzesd3kngj@affs2mpxg4gh>
 <CAE8JnxOQG=m_6-v-M_Nude5KRrOzAcbi2QPhySCJQ+e771BQHA@mail.gmail.com>
 <s5p7iou7pdhxhvmv4rohmskwqmr36dc4rybvwlep5yvwrjs4pa@6oxsemms5mw4>
In-Reply-To: <s5p7iou7pdhxhvmv4rohmskwqmr36dc4rybvwlep5yvwrjs4pa@6oxsemms5mw4>
From: Alexandre Felipe <o.alexandre.felipe@gmail.com>
Date: Thu, 5 Mar 2026 13:47:10 +0000
Message-ID: 
 <CAE8JnxNPK1T79gpS3PTPbFJB7W9rCLMwCZvJfYPR_mAZ-xibZw@mail.gmail.com>
Subject: Re: index prefetching
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas@vondra.me>, Peter Geoghegan <pg@bowt.ie>,
 Thomas Munro <thomas.munro@gmail.com>,
	Nazir Bilal Yavuz <byavuz81@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
	Melanie Plageman <melanieplageman@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Georgios <gkokolatos@protonmail.com>,
	Konstantin Knizhnik <knizhnik@garret.ru>, Dilip Kumar <dilipbalaut@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000015574e064c472da7"
Archived-At: 
 <https://www.postgresql.org/message-id/CAE8JnxNPK1T79gpS3PTPbFJB7W9rCLMwCZvJfYPR_mAZ-xibZw%40mail.gmail.com>
Precedence: bulk

--00000000000015574e064c472da7
Content-Type: text/plain; charset="UTF-8"

Thank you Andres,

I see, It combines an array that is fast for few buffers and a hash that in
theory
scales well for very large number of buffers. And avoids using an array that
would be fast but would multiply the memory usage by the number of backends.

> Index prefetching patch:
> uncorrelated: 228.936 ms
> correlated:   71.684  ms


I did some tests
> Possible improvements to refcount tracking:
>
> - increase REFCOUNT_ARRAY_ENTRIES - there's a very significant cliff at 8
>  right now, and with vectorized lookup it might not hurt too much to go
to 16
>  or so

Yes, that is true, but only up to 16, the index prefetch test I was doing
was
getting to 90 or so, and that was clipped by max_pinned_buffers.
Also, I noticed a commit 3 months ago that removed the mid-loop return
that effectively will add the first few pins right to left instead of left
to right.

Maybe this works well with vectorisation, but I see an optimization for the
for the (pin/unpin)+ sequence, what about the pin(pin/unpin)+ sequence.
The previous code would always find the buffers on the first or the second
iteration, the new implementation will have to go to the 7th or 8th
iteration,
(or I am not missing something very important).

> - To make the cliff at REFCOUNT_ARRAY_ENTRIES smaller, replace dynahash
with
>  simplehash. That should reduce the perf penalty a good bit.

This is also true, even remove the refcount array completely.

> Unfortunately it's not just the refcount tracking, it's also resowner
> management that gets more expensive.

I didn't read this sentence until I came back to reply. It is exactly what
I noticed.
Once we fix the reference counting the resowner still puts a floor.
And that is even more important when a buffer is pinned multiple times
because the resowner will add one entry to the buffer for each pin.

There is another problem, ResOwnerReleaseBuffer unlocks buffers,
even if it is not the owner of the lock.

I think this deserves a separate thread.

--00000000000015574e064c472da7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>Thank you Andres,</di=
v><div><br></div><div>I see, It combines an array that is fast for few buff=
ers and a hash that in theory</div><div>scales well for very large number o=
f buffers. And avoids using an array that</div><div>would be fast but would=
 multiply the memory usage by the number of backends.</div><div><br></div><=
div>&gt; Index prefetching patch:<br>&gt; uncorrelated: 228.936 ms<br>&gt; =
correlated:=C2=A0 =C2=A071.684=C2=A0 ms</div><div><br></div><div><br></div>=
<div>I did some tests<br>&gt; Possible improvements to refcount tracking:<b=
r>&gt;=C2=A0<br>&gt; - increase REFCOUNT_ARRAY_ENTRIES - there&#39;s a very=
 significant cliff at 8<br>&gt;=C2=A0 right now, and with vectorized lookup=
 it might not hurt too much to go to 16<br>&gt;=C2=A0 or so</div><div><br>Y=
es, that is true, but only up to 16, the index prefetch test I was doing wa=
s</div><div>getting to 90 or so, and that was clipped by max_pinned_buffers=
.</div><div>Also, I noticed a commit 3 months ago that removed the mid-loop=
 return</div><div>that effectively will add the first few pins right to lef=
t instead of left to right.</div><div><br></div><div>Maybe this works well =
with vectorisation, but I see an optimization for the</div><div>for the (pi=
n/unpin)+ sequence, what about the pin(pin/unpin)+ sequence.<br>The previou=
s code would always find the buffers on the first or the second</div><div>i=
teration, the new implementation will have to go to the 7th or 8th iteratio=
n,</div><div>(or I am not missing something very important).</div><div><br>=
</div><div>&gt; - To make the cliff at REFCOUNT_ARRAY_ENTRIES smaller, repl=
ace dynahash with<br>&gt;=C2=A0 simplehash. That should reduce the perf pen=
alty a good bit.</div><div><br>This is also true, even remove the refcount =
array completely.<br><br>&gt; Unfortunately it&#39;s not just the refcount =
tracking, it&#39;s also resowner<br>&gt; management that gets more expensiv=
e.<br><br>I didn&#39;t read this sentence until I came back to reply.=C2=A0=
It is exactly what I noticed.</div><div>Once we fix the reference counting =
the resowner still puts a floor.</div><div>And that is even more important =
when a buffer is pinned multiple times</div><div>because the resowner will =
add one entry to the buffer for each pin.<br><br>There is another problem,=
=C2=A0ResOwnerReleaseBuffer unlocks buffers,</div><div>even if it is not th=
e owner of the lock.</div><div><br></div><div>I think this deserves a separ=
ate thread.</div><div><br></div><div><br></div></div>
</div>

--00000000000015574e064c472da7--