Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Date: 2012-08-15 15:51:58
Message-ID: 6646.1345045918@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> 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.

To me it's more about future-proofing.  commit_delay is the only
time-interval setting we've got where reasonable values today are in the
single-digit-millisecond range.  So it seems to me not hard to infer
that in a few years sub-millisecond values will be important, whether or
not there's any real argument for them today.

			regards, tom lane


In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2012-08-15 16:00:53
Subject: Re: sha1, sha2 functions into core?
Previous:From: Merlin MoncureDate: 2012-08-15 15:49:50
Subject: Re: sha1, sha2 functions into core?

pgsql-committers by date

Next:From: Bruce MomjianDate: 2012-08-15 16:01:08
Subject: pgsql: Add C comment that '=' is not documented for plpgsqlassignment.
Previous:From: Bruce MomjianDate: 2012-08-15 15:47:21
Subject: pgsql: Document that foreign "version" and "type" values are onlyusefu

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group