public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v3 03/10] read_stream: Issue IO synchronously while in fast path 2+ messages / 1 participants [nested] [flat]
* [PATCH v3 03/10] read_stream: Issue IO synchronously while in fast path @ 2026-03-03 21:25 Andres Freund <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Andres Freund @ 2026-03-03 21:25 UTC (permalink / raw) While in fast-path, execute any IO that we might encounter synchronously. Because we are, in that moment, not reading ahead, dispatching any occasional IO to workers has the dispatch overhead, without any realistic chance of the IO completing before we need it. This helps io_method=worker performance for workloads that have only occasional cache misses, but where those occasional misses still take long enough to matter. It is likely this is only measurable with fast local storage or workloads with the data in the kernel page cache, as with remote storage the IO latency, not the dispatch-to-worker latency, is the determining factor. Author: Reviewed-by: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/aio/read_stream.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/src/backend/storage/aio/read_stream.c b/src/backend/storage/aio/read_stream.c index cd54c1a74ac..7893fdf03d3 100644 --- a/src/backend/storage/aio/read_stream.c +++ b/src/backend/storage/aio/read_stream.c @@ -833,6 +833,21 @@ read_stream_next_buffer(ReadStream *stream, void **per_buffer_data) if (stream->advice_enabled) flags |= READ_BUFFERS_ISSUE_ADVICE; + /* + * While in fast-path, execute any IO that we might encounter + * synchronously. Because we are, right now, only looking one + * block ahead, dispatching any occasional IO to workers would + * have the overhead of dispatching to workers, without any + * realistic chance of the IO completing before we need it. We + * will switch to non-synchronous IO after this. + * + * Arguably we should do so only for worker, as there's far less + * dispatch overhead with io_uring. However, tests so far have not + * shown a clear downside and additional io_method awareness here + * seems not great from an abstraction POV. + */ + flags |= READ_BUFFERS_SYNCHRONOUSLY; + /* * Pin a buffer for the next call. Same buffer entry, and * arbitrary I/O entry (they're all free). We don't have to @@ -860,6 +875,12 @@ read_stream_next_buffer(ReadStream *stream, void **per_buffer_data) stream->ios_in_progress = 1; stream->ios[0].buffer_index = oldest_buffer_index; stream->seq_blocknum = next_blocknum + 1; + + /* + * XXX: It might be worth triggering additional readahead here, to + * avoid having to effectively do another synchronous IO for the + * next block (if it were also a miss). + */ } else { -- 2.53.0.1.gb2826b52eb --biispz4aupeya6ku Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v3-0004-read_stream-Prevent-distance-from-decaying-too-qu.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* [PATCH v4 01/14] read_stream: Issue IO synchronously while in fast path @ 2026-04-01 22:39 Andres Freund <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Andres Freund @ 2026-04-01 22:39 UTC (permalink / raw) While in fast-path, execute any IO that we might encounter synchronously. Because we are, in that moment, not reading ahead, dispatching any occasional IO to workers has the dispatch overhead, without any realistic chance of the IO completing before we need it. This helps io_method=worker performance for workloads that have only occasional cache misses, but where those occasional misses still take long enough to matter. It is likely this is only measurable with fast local storage or workloads with the data in the kernel page cache, as with remote storage the IO latency, not the dispatch-to-worker latency, is the determining factor. Reviewed-by: Melanie Plageman <[email protected]> Reviewed-by: Nazir Bilal Yavuz <[email protected]> Discussion: https://postgr.es/m/f3xxfrkafjxpyqxywcxricxgyizjirfceychyxsgn7bwjp5eda@kwbduhy7tfmu Discussion: https://postgr.es/m/CAH2-Wz%3DkMg3PNay96cHMT0LFwtxP-cQSRZTZzh1Cixxf8G%3Dzrw%40mail.gmail.com --- src/backend/storage/aio/read_stream.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/src/backend/storage/aio/read_stream.c b/src/backend/storage/aio/read_stream.c index cd54c1a74ac..c9595ea10c7 100644 --- a/src/backend/storage/aio/read_stream.c +++ b/src/backend/storage/aio/read_stream.c @@ -833,6 +833,21 @@ read_stream_next_buffer(ReadStream *stream, void **per_buffer_data) if (stream->advice_enabled) flags |= READ_BUFFERS_ISSUE_ADVICE; + /* + * While in fast-path, execute any IO that we might encounter + * synchronously. Because we are, right now, only looking one + * block ahead, dispatching any occasional IO to workers would + * have the overhead of dispatching to workers, without any + * realistic chance of the IO completing before we need it. We + * will switch to non-synchronous IO after this. + * + * Arguably we should do so only for worker, as there's far less + * dispatch overhead with io_uring. However, tests so far have not + * shown a clear downside and additional io_method awareness here + * seems not great from an abstraction POV. + */ + flags |= READ_BUFFERS_SYNCHRONOUSLY; + /* * Pin a buffer for the next call. Same buffer entry, and * arbitrary I/O entry (they're all free). We don't have to @@ -860,6 +875,12 @@ read_stream_next_buffer(ReadStream *stream, void **per_buffer_data) stream->ios_in_progress = 1; stream->ios[0].buffer_index = oldest_buffer_index; stream->seq_blocknum = next_blocknum + 1; + + /* + * XXX: It might be worth triggering additional read-ahead here, + * to avoid having to effectively do another synchronous IO for + * the next block (if it were also a miss). + */ } else { -- 2.53.0.1.gb2826b52eb --ik3l34cft6pr4f53 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v4-0002-read_stream-Prevent-distance-from-decaying-too-qu.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-04-01 22:39 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-03-03 21:25 [PATCH v3 03/10] read_stream: Issue IO synchronously while in fast path Andres Freund <[email protected]> 2026-04-01 22:39 [PATCH v4 01/14] read_stream: Issue IO synchronously while in fast path Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox