Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
От | Andres Freund |
---|---|
Тема | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |
Дата | |
Msg-id | 201011052154.57775.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |
Список | pgsql-hackers |
On Friday 05 November 2010 19:13:47 Tom Lane wrote: > Marti Raudsepp <marti@juffo.org> writes: > > PostgreSQL's default settings change when built with Linux kernel > > headers 2.6.33 or newer. As discussed on the pgsql-performance list, > > this causes a significant performance regression: > > http://archives.postgresql.org/pgsql-performance/2010-10/msg00602.php > > > > NB! I am not proposing to change the default -- to the contrary -- > > this patch restores old behavior. > > I'm less than convinced this is the right approach ... > > 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? Andres
В списке pgsql-hackers по дате отправления: