the trick of flushing the disk cache.
Dan
- Original Message -
From: Andres Freund and...@anarazel.de
To: pgsql-hackers@postgresql.org
Cc: Dan Scales sca...@vmware.com
Sent: Monday, February 27, 2012 12:43:49 PM
Subject: Re: [HACKERS] possible new option for wal_sync_method
Hi
Hi,
On Friday, February 17, 2012 01:17:27 AM Dan Scales wrote:
Good point, thanks. From the ext3 source code, it looks like
ext3_sync_file() does a blkdev_issue_flush(), which issues a flush to the
block device, whereas simple direct IO does not. So, that would make
this wal_sync_method
When running Postgres on a single ext3 filesystem on Linux, we find that
the attached simple patch gives significant performance benefit (7-8% in
numbers below). The patch adds a new option for wal_sync_method, which
is open_direct. With this option, the WAL is always opened with
O_DIRECT (but
Hi,
On Thursday, February 16, 2012 06:18:23 PM Dan Scales wrote:
When running Postgres on a single ext3 filesystem on Linux, we find that
the attached simple patch gives significant performance benefit (7-8% in
numbers below). The patch adds a new option for wal_sync_method, which
is
On Thu, Feb 16, 2012 at 19:18, Dan Scales sca...@vmware.com wrote:
fsync/fdatasync can be very slow on ext3, because it seems to have to
always wait for the current filesystem meta-data transaction to complete,
even if that meta-data operation is completely unrelated to the file
being
On 2/16/12 9:18 AM, Dan Scales wrote:
Do folks have any interest in this change, or comments on its
usefulness/correctness? It would be just an extra option for
wal_sync_method that users can try out and has benefits for certain
configurations.
Does it have any benefit on Ext4/XFS/Butrfs?
: Andres Freund and...@anarazel.de
To: pgsql-hackers@postgresql.org
Cc: Dan Scales sca...@vmware.com
Sent: Thursday, February 16, 2012 10:32:09 AM
Subject: Re: [HACKERS] possible new option for wal_sync_method
Hi,
On Thursday, February 16, 2012 06:18:23 PM Dan Scales wrote:
When running Postgres
