Re: improving concurrent transactin commit rate

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: improving concurrent transactin commit rate
Дата
Msg-id 24562.1237994150@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: improving concurrent transactin commit rate  (Greg Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Greg Stark <stark@enterprisedb.com> writes:
> What happens is that the first backend comes along, finds nobody else waiting
> and does an fsync for its own work. While that fsync is happening the rest of
> the crowd -- N-1 backends -- comes along and blocks waiting on the lock. The
> first backend to get the lock fsyncs the whole N-1 transactions. When it's
> done though the whole crowd finds the log already syncs and goes back to work.
> The first transaction to commit again finds nobody waiting and syncs alone
> again. rinse lather repeat.

Right.  The idea of the commit-delay stuff is to avoid that by letting
the first guy wait a little bit before starting to sync, but as
mentioned, we've never been able to get it to work real well.
        regards, tom lane


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: shut down pgsql-interfaces (was Re: Function C and INOUT parameters)
Следующее
От: Guillaume Smet
Дата:
Сообщение: Re: New trigger option of pg_standby