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

On 15 August 2012 05:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> On 14 August 2012 21:26, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> Revert "commit_delay" change; just add comment that we don't have
>>> a microsecond specification.
>
>> I think that if we eventually decide to change the name of
>> commit_delay for 9.3 (you previously suggested that that might be
>> revisited), it will be reasonable to have the new GUC in units of
>> milliseconds.
>
> Well, the reason why it's like that at all is the thought that values
> of less than 1 millisecond might be useful. Are we prepared to suppose
> that that is not and never will be true?

I think that the need for sub-millisecond granularity had more to do
with historic quirks of our implementation. Slight tweaks accidentally
greatly improved throughput, if only for the synthetic benchmark in
question. I personally have not seen any need for a sub-millisecond
granularity when experimenting with the setting on 9.3-devel. However,
I am not sure that sub-millisecond granularity could never be of any
use, in squeezing the last small increase in throughput made possible
by commit_delay. Importantly, feedback as the GUC is tuned is far more
predictable than it was with the prior implementation, so this does
seem quite unimportant.

Why does commit_delay have to be an integer? Can't we devise a way of
manipulating it in units of milliseconds, but have the internal
representation be a double, as with pg_stat_statements' total_time
column? That would allow very fine tuning of the delay. As I've
outlined, I'm not sure that it's worth supporting such fine-tuning
with the new implementation.

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