Re: Group Commits Vs WAL Writes

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

In response to

Responses

Browse pgsql-hackers by date

  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.