From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Group Commits Vs WAL Writes |
Date: | 2013-06-27 16:35:33 |
Message-ID: | CAM3SWZS0AUQTeCWxuboGigXHur-adC_mGRTJGp_nFsjbEt3O4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 27, 2013 at 12:56 AM, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> wrote:
> Now, with group commits, do we see a spike in that disk write latency,
> especially in the cases where the user has set wal_buffers to a high
> value?
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.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2013-06-27 16:42:06 | Re: [PATCH] add --progress option to pgbench (submission 3) |
Previous Message | Nicolas Barbier | 2013-06-27 16:35:24 | Re: Hash partitioning. |