Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
Дата
Msg-id 27641.1288980827@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Marti Raudsepp <marti@juffo.org>)
Ответы Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Marti Raudsepp <marti@juffo.org>)
Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Andres Freund <andres@anarazel.de>)
Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-hackers
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?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE ... IF EXISTS feature?
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: ALTER OBJECT any_name SET SCHEMA name