Re: macOS prefetching support

On 17.08.24 00:01, Thomas Munro wrote:
> On Sat, Aug 17, 2024 at 6:58 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> What to do about the order of the symbols and include files. I threw
>> something into src/include/port/darwin.h, but I'm not sure if that's
>> good. Alternatively, we could not use __darwin__ but instead the more
>> standard and predefined defined(__APPLE__) && defined(__MACH__).
>
> Hmm. fd.h and fd.c test for F_NOCACHE, which is pretty closely
> related. Now I'm wondering why we actually need this in
> pg_config_manual.h at all. Who would turn it off at compile time, and
> why would they not be satisfied with setting relevant GUCs to 0? Can
> we just teach fd.h to define USE_PREFETCH if
> defined(POSIX_FADV_WILLNEED) || defined(F_RDADVISE)?

I thought USE_PREFETCH existed so that we don't have the run-time
overhead for all the bookkeeping code if we don't have any OS-level
prefetch support at the end. But it looks like most of that bookkeeping
code is skipped anyway if the *_io_concurrency settings are at 0. So
yes, getting rid of USE_PREFETCH globally would be useful.

> (I have also thought multiple times about removing the configure
> probes for F_FULLFSYNC, and just doing #ifdef. Oh, that's in my patch
> for CF #4453.)

Understandable, but we should be careful here that we don't create
setups that can cause bugs like
<https://www.postgresql.org/message-id/48da4a1f-ccd9-4988-9622-24f37b1de2b4@eisentraut.org>.

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