Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Date
Msg-id CAEYLb_WNUODiZqUW2bTm_kWOoV4GJS64e2iAyoJvT2_kjDtnEg@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Re: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
List pgsql-hackers
On 15 August 2012 14:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If you wanted to re-implement all the guc.c logic for supporting
> unit-ified values such that it would also work with floats, we could
> do that.  It seems like way more mechanism than the problem is worth
> however.

Fair enough.

I'm not quite comfortable recommending a switch to milliseconds if
that implies a loss of sub-millisecond granularity. I know that
someone is going to point out that in some particularly benchmark,
they can get another relatively modest increase in throughput (perhaps
2%-3%) by splitting the difference between two adjoining millisecond
integer values. In that scenario, I'd be tempted to point out that
that increase is quite unlikely to carry over to real-world benefits,
because the setting is then right on the cusp of where increasing
commit_delay stops helping throughput and starts hurting it. The
improvement is likely to get lost in the noise in the context of a
real-world application, where for example the actually cost of an
fsync is more variable. I'm just not sure that that's the right
attitude.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_stat_replication vs StandbyReplyMessage
Next
From: Bruce Momjian
Date:
Subject: Re: sha1, sha2 functions into core?