From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Marti Raudsepp <marti(at)juffo(dot)org> |
Subject: | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |
Date: | 2010-11-05 22:07:10 |
Message-ID: | 3002.1288994830@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On Friday 05 November 2010 19:13:47 Tom Lane wrote:
>> If open_dsync is so bad for performance on Linux, maybe it's bad
>> everywhere? Should we be rethinking the default preference order?
> I fail to see how it could be beneficial on *any* non-buggy platform.
> Especially with small wal_buffers and larger commits (but also otherwise) it
> increases the amount of synchronous writes the os has to do tremendously.
> * It removes about all benefits of XLogBackgroundFlush()
> * It removes any chances of reordering after writing.
> * It makes AdvanceXLInsertBuffer synchronous if it has to write outy
> Whats the theory about placing it so high in the preferences list?
I think the original idea was that if you had a dedicated WAL drive then
sync-on-write would be reasonable. But that was a very long time ago
and I'm not sure that the system's behavior is anything like what it was
then; for that matter I'm not sure we had proof that it was an optimal
choice even back then. That's why I want to revisit the choice of
default and not just go for "minimum" change.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2010-11-05 22:08:00 | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |
Previous Message | Tom Lane | 2010-11-05 22:03:20 | Re: Query Plan Columns |