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
|
Список | 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 по дате отправления: