Re: Streamify more code paths

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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-11 02:22:51
Message-ID: CABPTF7X9Q8UsKBV6_V2pEQ5rgs=0QMhUjT72m+TkHmJpru7N2Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, Mar 11, 2026 at 7:29 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Mar 10, 2026 at 07:04:37PM -0400, Andres Freund wrote:
> > It might be a good idea to run the benchmarks with debug_io_direct=data.
> > That'll make them very slow, since the write side doesn't yet use AIO and thus
> > will do a lot of synchronous writes, but it should still allow to evaluate the
> > gains from using read stream.
>
> Ah, thanks for the tip. I'll go try that.
>
> > The other thing that's kinda important to evaluate read streams is to test on
> > higher latency storage, even without direct IO. Many workloads are not at all
> > benefiting from AIO when run on a local NVMe SSD with < 10us latency, but are
> > severely IO bound when run on a cloud storage disk with 0.5ms - 4ms latency.
>
> My previous run was on a cloud instance, I don't have access to a SSD
> with this amount of latency locally.
>
> One thing that was standing on is the bloom bitmap case that was
> looking really nice for a large number of rows, so I have applied
> this part. The rest is going to need a bit more testing to build more
> confidence, as far as I can see.
> --
> Michael

Thanks for pushing that. I’ll update the script with Andres’
suggestions and share it shortly.

--
Best,
Xuneng

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2026-03-11 02:23:36 Re: Streamify more code paths
Previous Message Xuneng Zhou 2026-03-11 02:13:02 Re: Streamify more code paths