Re: Streamify more code paths

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Subject: Re: Streamify more code paths
Date: 2026-03-16 01:00:41
Message-ID: abdWOU1wY7JI3AXr@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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:
>
> hash_vacuum_medium base= 33747.2ms patch= 27379.7ms 1.23x ( 18.9%)
> read: 4662→1612 ops 8238.72→1725.86ms
> (4.77x) write: 12689→12651 ops 25146.51→25053.57ms (1.00x)
>
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-03-16 01:08:22 Re: pgcrypto/des tests fail on riscv64 due to clang's code generation anomaly
Previous Message Chao Li 2026-03-16 00:50:55 Re: Use SMgrRelation instead of SMgrRelationData * in pgaio_io_set_target_smgr()