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

• Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav at 2012-08-15 15:41:38 from Peter Geoghegan

pgsql-hackers by date

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

pgsql-committers by date

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