Re: Streamify more code paths

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Xuneng Zhou <xunengzhou(at)gmail(dot)com>, 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-10 23:29:51
Message-ID: abCpb4VBwmzn9s_P@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-03-11 00:00:34 Re: Remove header lock BufferGetLSNAtomic() on architectures with 64 bit atomic operations
Previous Message Andres Freund 2026-03-10 23:27:59 Re: Streamify more code paths