Re: Should io_method=worker remain the default? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Should io_method=worker remain the default?
Date
Msg-id e38072d7f6e44ad60e7b5bbf23298470937f08db.camel@j-davis.com
Whole thread Raw
In response to Re: Should io_method=worker remain the default?  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
On Wed, 2025-09-03 at 10:34 +0200, Tomas Vondra wrote:
> I'll try to reproduce this, but if it's due to the same IPC overhead,
> that would be surprising (for me). In the index case it makes sense,
> because the reads are random enough to prevent I/O combining. But for
> a
> sequential workload I'd expect I/O combining to help. Could it be
> that
> it ends up evicting buffers randomly, which (I guess) might interfere
> with the combining? What's shared_buffers set to?

I left it as the default (128MB).

>  Have you watched how
> large the I/O requests are? iostat, iosnoop or strace would tell you.

In my test there's not much device IO, because the data is cached. I
used:

  strace -p $io_worker_pid -e trace=preadv

and looked briefly at the output. iov_len seems to range between 8kB
and about 128kB, but still a lot of 8kB. That's from a very brief look,
I can try to get more precise numbers, but there seem to be enough 8kB
ones to support your theory.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: [PATCH] Hex-coding optimizations using SVE on ARM.
Next
From: Peter Eisentraut
Date:
Subject: Re: Cannot find a working 64-bit integer type on Illumos