Re: Windows now has fdatasync()
От | Thomas Munro |
---|---|
Тема | Re: Windows now has fdatasync() |
Дата | |
Msg-id | CA+hUKG+uLZcB+b+w0OcN5i4pDLiA0Nao2oSMb+HE8j3ZuRCDyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Windows now has fdatasync() (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Windows now has fdatasync()
|
Список | pgsql-hackers |
On Sun, Feb 6, 2022 at 7:20 PM Michael Paquier <michael@paquier.xyz> wrote: > On Sun, Dec 12, 2021 at 03:48:10PM +1300, Thomas Munro wrote: > > I tried out a quick POC patch and it runs a bit faster than fsync(), as > > expected. > > Good news, as a too high difference would be suspect :) > > How much difference does it make in % and are the numbers rather > reproducible? Just wondering.. I've only tested on a qemu/kvm virtual machine with a virtual SATA disk device, so take this with a bucket of salt, but I think that's enough to see the impact of 'slow' SATA commands hitting the device and being waited for, and what I see is that wal_sync_method=fdatasync does about 25% more TPS than wal_sync_method=fsync, and wal_sync_method=open_datasync is a wildly higher number that I don't believe (ie I don't believe it waited for power loss durability and the links above support that understanding), but tumbles back to earth and almost exactly matches the wal_sync_method=fdatasync number when the write cache is disabled.
В списке pgsql-hackers по дате отправления: