Re: Group Commits Vs WAL Writes

Поиск
Список
Период
Сортировка
От Atri Sharma
Тема Re: Group Commits Vs WAL Writes
Дата
Msg-id CAOeZVifktS0L+UHJj0WoAa_LCTKr3AYe+7P5r2mazG+JPsuB8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Group Commits Vs WAL Writes  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Group Commits Vs WAL Writes  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
>
> commit_delay exists to artificially increase the window in which the
> leader backend waits for more group commit followers. At higher client
> counts, that isn't terribly useful because you'll naturally have
> enough clients anyway, but at lower client counts particularly where
> fsyncs have high latency, it can help quite a bit. I mention this
> because clearly commit_delay is intended to trade off latency for
> throughput. Although having said that, when I worked on commit_delay,
> the average and worse-case latencies actually *improved* for the
> workload in question, which consisted of lots of small write
> transactions. Though I wouldn't be surprised if you could produce a
> reasonable case where latency was hurt a bit, but throughput improved.

Thanks for your reply.

The logic says that latency will be hit when commit_delay is applied,
but I am really interested in why we get an improvement instead.

Can small writes be the reason?

Regards,

Atri


--
Regards,

Atri
l'apprenant



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: MD5 aggregate
Следующее
От: Atri Sharma
Дата:
Сообщение: Re: Group Commits Vs WAL Writes