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
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. |