From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Group Commits Vs WAL Writes |
Date: | 2013-06-27 16:51:43 |
Message-ID: | CAOeZVifktS0L+UHJj0WoAa_LCTKr3AYe+7P5r2mazG+JPsuB8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2013-06-27 16:54:34 | Re: Group Commits Vs WAL Writes |
Previous Message | Peter Eisentraut | 2013-06-27 16:47:49 | Re: MD5 aggregate |