| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера