| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Mats Kindahl <mats(dot)kindahl(at)gmail(dot)com> |
| Cc: | Markos Fountoulakis <markos(at)planetscale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Recovery does not honor io_combine_limit, causing IOPS saturation |
| Date: | 2026-11-11 06:24:42 |
| Message-ID: | CB4A7C55-F40D-42C9-A6A7-265E6AFE157A@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Mats, Markos,
On 9 Nov 2026, Mats Kindahl wrote:
> The patch still helps CPU at large limits:
Could you also share a comparison with both WAL and relation pages
already cached? That should make it easier to see whether the saved
syscalls outweigh the additional copying, without the storage throughput
limit dominating elapsed time.
One part of my earlier comment still seems to apply to v2: for
XLOG_FROM_STREAM, wanted is capped to readLen, which is at most
XLOG_BLCKSZ. That path still fills the cache one page at a time, so it
adds a memcpy without combining streaming reads. Could the fill size
and valid-byte count instead be bounded by the available WAL from
targetPagePtr to flushedUpto?
Thank you!
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-11-11 06:46:58 | Re: [PATCH] Fix two client-side NULL dereferences on malformed result sets (libpq, pg_receivewal) |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-11-11 05:57:55 | RE: [PATCH] Explain what the default output_plugin_libraries do |