From: Robert Haas
I also said it would be worse on spinning disks.
Also, Yoshimi Ichiyanagi did not find it to be true even on NVRAM.
Yes, let me withdraw this proposal. I couldn't see any performance
difference even with ext4 volume on a PCIe flash memory.
Regards
MauMau
On Mon, Feb 19, 2018 at 7:27 PM, Tsunakawa, Takayuki
wrote:
> The reason for change is better performance. Robert Haas said open_datasync
> was much faster than fdatasync with NVRAM in this thread:
I also said it would be worse on spinning disks.
Also, Yoshimi Ichiyanagi did not find it to be
On 2018-02-20 01:56:17 +, Tsunakawa, Takayuki wrote:
> Disabling the filesystem barrier is a valid tuning method as the PG manual
> says:
I don't think it says that:
> https://www.postgresql.org/docs/devel/static/wal-reliability.html
>
> [Excerpt]
> Recent SATA drives (those following ATAPI
From: Mark Kirkwood [mailto:mark.kirkw...@catalyst.net.nz]
> I think the use of 'nobarrier' is probably disabling most/all reliable
> writing to the devices. What do the numbers look like if use remove this
> option?
Disabling the filesystem barrier is a valid tuning method as the PG manual says:
From: Andres Freund [mailto:and...@anarazel.de]
> Indeed. My past experience with open_datasync on linux shows it to be slower
> by roughly an order of magnitude. Even if that would turn out not to be
> the case anymore, I'm *extremely* hesitant to make such a change.
Thanks for giving so quick fe
On 20/02/18 13:27, Tsunakawa, Takayuki wrote:
Hello,
I propose changing the default value of wal_sync_method from fdatasync to
open_datasync on Linux. The patch is attached. I'm feeling this may be
controversial, so I'd like to hear your opinions.
The reason for change is better performanc
Hi,
On 2018-02-20 00:27:47 +, Tsunakawa, Takayuki wrote:
> I propose changing the default value of wal_sync_method from fdatasync
> to open_datasync on Linux. The patch is attached. I'm feeling this
> may be controversial, so I'd like to hear your opinions.
Indeed. My past experience with o
