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