Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 16 Mar 2026 10:00:41 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
	pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
	Nazir Bilal Yavuz <byavuz81@gmail.com>
Subject: Re: Streamify more code paths
Message-ID: <abdWOU1wY7JI3AXr@paquier.xyz>
References: 
 <CABPTF7X3RBkmOnQAoLbK-tr6o-+27fNpKPgzYZHhQCuYbP=rGA@mail.gmail.com>
 <abHflCRN5CM0d8Dc@paquier.xyz>
 <abI2JBc5J_Erlgqr@paquier.xyz>
 <CABPTF7Wz8OCcr2f1CSdt-jRHfJAAdXZwwBokBD4baZAPyK7CgA@mail.gmail.com>
 <CABPTF7UA3sEw1ZpAj8qAKY6Xs71sk41X-pV43_iZHZz2U_AP=Q@mail.gmail.com>
 <abNtReiW-Y8NqxGg@paquier.xyz>
 <CABPTF7XxdAA681duGKgWx-eLC1skR3giuebcw4+-0GkOVZm-pw@mail.gmail.com>
 <abUw12rWiI-ajy5v@paquier.xyz>
 <CABPTF7U4CvFp55wVg51b8b24J1GQfjB62SzvfXY0ZgjaRWPYfA@mail.gmail.com>
 <CABPTF7WONbvOOJPKwpPmh0Pu6scFZbCwxKq5ThdPiWEfdMjfjA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="HvpL1o1Dq9R7/rNj"
Content-Disposition: inline
In-Reply-To: 
 <CABPTF7WONbvOOJPKwpPmh0Pu6scFZbCwxKq5ThdPiWEfdMjfjA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/abdWOU1wY7JI3AXr%40paquier.xyz>
Precedence: bulk


--HvpL1o1Dq9R7/rNj
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 15, 2026 at 11:47:06AM +0800, Xuneng Zhou wrote:
> The updated script now reports speedup separately for the read and
> write paths like this:
>=20
> hash_vacuum_medium         base=3D 33747.2ms  patch=3D 27379.7ms   1.23x =
 ( 18.9%)
>                              read:  4662=E2=86=921612 ops  8238.72=E2=86=
=921725.86ms
> (4.77x)    write:  12689=E2=86=9212651 ops  25146.51=E2=86=9225053.57ms  =
(1.00x)
>=20
> I think it is useful to keep the write-delay option even with this
> reporting. Separating the read and write delays also helps reduce the
> overall runtime of the tests, especially for large data sizes: we only
> slow down the read path while keeping the write path fast.

These write numbers are more in line with what I was seeing in my last
tests, and I am not going to ignore a 20% runtime reduction.  The
stats numbers are looking nice, as well.

At the end, I have checked the logic of what you are introducing,
where things come down to the point of making sure that the data
pushed to the callback remains consistent with the paths where
_hash_getcachedmetap() is called.  I have also cross-checked the data
reports by pgstattuple for the relation and the index, to see that
these are consistent between HEAD and the patch, just in case.  And
applied it.  That was the last piece.
--
Michael

--HvpL1o1Dq9R7/rNj
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmm3VjkACgkQnvQgOdby
QH34jQ//dCcQwEHbTzGzD1nZii9rJy2SnUOWuOrd+6SF+98APgazvC9iFB9EnfcC
y38iD+Ht5cfRz8pQtfvLXIpe4BpomLcGSK9GgjQ9HinD80PASqrWecSI5i0cE6wc
/URflIWUjQ5eRF6CPw85BWf0BFFbF5p+quStYP3xfdOe0VBGdGcbE6G37u0ijsYx
LCWuy1ukujbRVK4m5M8aSj1qnuG6kpzluRhSRLNzRdIc/1JmXDmn4NuYZWeAdHW3
n+lRvx8rqm+EPWoq3PiAN+oSjoIDeA7a1fNGldj12mxEh3NRNThXXqkstv4qlTAO
MPc2jlB12VEOgw0b4agDKkM9UdaKtYGKOTvUQQibrWDYPMBtGHH3ET6jFIi9zinB
gmkq0qQg96QtnNnCjVx+vZEcEXxNahYDgfhAMGFKvBUzIY/m5s1gtSP+MuR2uogl
ZjETVFb5SK+HASX5JuLlsqa0p9kx5t1Cq7t/kWN6q25WevARbtvUlEHWoFOMenaZ
d63XL8pHtFK4QRANXRWW4/ZFtCd3z+d5nZEmUohymn4CUhUHLIN8P1Pnn2kZqzxr
6fEFy+VYo9RW6d/+5B+38xInQIM/EAlK6d/hu75qPV1kHfNaMQYn+zM5IYZEf/Q8
fqt2y0T5MwaaNI6JVush1RZQ7OJ0qbmBILrjCYg26NeHoMTQp8g=
=yFUk
-----END PGP SIGNATURE-----

--HvpL1o1Dq9R7/rNj--