Re: O_DIRECT on macOS

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: O_DIRECT on macOS
Date: 2021-07-20 05:01:43
Message-ID: CA+hUKGJE+gBTzBH9=3o94qQjsULDDHYBYKRXjXN862G2kZDL3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 20, 2021 at 12:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I can try that on the gcc farm in a bit.

Thanks!

> Hmm, it compiles cleanly, but something seems drastically wrong,
> because performance is just awful. On the other hand, I don't
> know what sort of storage is underlying this instance, so maybe
> that's to be expected?

Ouch. I assume this was without wal_method=minimal (or it'd have
reached the new code and failed completely, based on the pg_test_fsync
result).

> open_datasync n/a*

I'm waiting for access, but I see from man pages that closed source
ZFS doesn't accept DIRECTIO_ON, so it may not be possible to see it
work on an all-ZFS system that you can't mount a new FS on. Hmm.
Well, many OSes have file systems that can't do it (ext4 journal=data,
etc). One problem is that we don't treat all OSes the same when
selecting wal_sync_method, even though O_DIRECT is complicated on many
OSes. It would also be nice if the choice to use direct I/O were
independently controlled, and ... [trails off]. Alright, I'll leave
this on ice for now.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-07-20 05:04:19 Re: Speed up transaction completion faster after many relations are accessed in a transaction
Previous Message David Rowley 2021-07-20 04:50:09 Re: Avoid stack frame setup in performance critical routines using tail calls