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+  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Query Plan Columns
Следующее
От: Marti Raudsepp
Дата:
Сообщение: Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+