Re: Should io_method=worker remain the default?
От | Jeff Davis |
---|---|
Тема | Re: Should io_method=worker remain the default? |
Дата | |
Msg-id | e38072d7f6e44ad60e7b5bbf23298470937f08db.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Should io_method=worker remain the default? (Tomas Vondra <tomas@vondra.me>) |
Список | 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 по дате отправления: