Re: Should io_method=worker remain the default?

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tomas Vondra <tomas(at)vondra(dot)me>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should io_method=worker remain the default?
Date: 2025-09-03 14:50:50
Message-ID: e38072d7f6e44ad60e7b5bbf23298470937f08db.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-09-03 15:04:03 Re: Cannot find a working 64-bit integer type on Illumos
Previous Message Nathan Bossart 2025-09-03 14:48:57 Re: [PATCH] Hex-coding optimizations using SVE on ARM.