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