On Mon, Aug 19, 2024 at 1:35 AM Peter Eisentraut <pe...@eisentraut.org> wrote: > On 17.08.24 00:01, Thomas Munro wrote: > > I think that's fine. I don't really like the word "prefetch", could > > mean many different things. What about "requires OS support for > > issuing read-ahead advice", which uses a word that appears in both of > > those interfaces? > > I like that term.
A couple of other places still use the old specific terminology. PSA.
From 287a56f8d177e56983d68cdd7201866ba119c130 Mon Sep 17 00:00:00 2001 From: Thomas Munro <thomas.mu...@gmail.com> Date: Tue, 3 Sep 2024 13:30:22 +1200 Subject: [PATCH] Standardize "read-ahead advice" terminology. Commit 6654bb920 added macOS's equivalent of POSIX_FADV_WILLNEED, and adjusted a few explicit references to posix_fadvise to use a more general name for the concept. Update some remaining references. Reviewed-by: Discussion: https://postgr.es/m/0827edec-1317-4917-a186-035eb1e3241d%40eisentraut.org --- src/backend/access/transam/xlogprefetcher.c | 2 +- src/backend/storage/aio/read_stream.c | 17 +++++++++-------- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/src/backend/access/transam/xlogprefetcher.c b/src/backend/access/transam/xlogprefetcher.c index 3cb698d3bcb..3acaaea5b70 100644 --- a/src/backend/access/transam/xlogprefetcher.c +++ b/src/backend/access/transam/xlogprefetcher.c @@ -1083,7 +1083,7 @@ check_recovery_prefetch(int *new_value, void **extra, GucSource source) #ifndef USE_PREFETCH if (*new_value == RECOVERY_PREFETCH_ON) { - GUC_check_errdetail("\"recovery_prefetch\" is not supported on platforms that lack posix_fadvise()."); + GUC_check_errdetail("\"recovery_prefetch\" is not supported on platforms that lack support for issuing read-ahead advice."); return false; } #endif diff --git a/src/backend/storage/aio/read_stream.c b/src/backend/storage/aio/read_stream.c index 93cdd35fea0..aae92e6b1f8 100644 --- a/src/backend/storage/aio/read_stream.c +++ b/src/backend/storage/aio/read_stream.c @@ -24,16 +24,17 @@ * already. There is no benefit to looking ahead more than one block, so * distance is 1. This is the default initial assumption. * - * B) I/O is necessary, but fadvise is undesirable because the access is - * sequential, or impossible because direct I/O is enabled or the system - * doesn't support fadvise. There is no benefit in looking ahead more than + * B) I/O is necessary, but read-ahead advice is undesirable because the access + * is sequential and we can rely on the kernel's read-ahead heuristics, or + * impossible because direct I/O is enabled, or the system doesn't support + * read-ahead advice. There is no benefit in looking ahead more than * io_combine_limit, because in this case the only goal is larger read system - * calls. Looking further ahead would pin many buffers and perform - * speculative work looking ahead for no benefit. + * calls. Looking further ahead would pin many buffers and perform speculative + * work for no benefit. * - * C) I/O is necessary, it appears random, and this system supports fadvise. - * We'll look further ahead in order to reach the configured level of I/O - * concurrency. + * C) I/O is necessary, it appears to be random, and this system supports + * read-ahead advice. We'll look further ahead in order to reach the + * configured level of I/O concurrency. * * The distance increases rapidly and decays slowly, so that it moves towards * those levels as different I/O patterns are discovered. For example, a -- 2.46.0
