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

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

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-committers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Date: 2012-08-15 10:51:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
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
PostgreSQL Development, 24x7 Support, Training and Services

In response to


pgsql-hackers by date

Next:From: Marko KreenDate: 2012-08-15 11:42:13
Subject: Re: sha1, sha2 functions into core?
Previous:From: Etsuro FujitaDate: 2012-08-15 09:17:37
Subject: Don't allow relative path for copy from file

pgsql-committers by date

Next:From: Tom LaneDate: 2012-08-15 13:39:38
Subject: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Previous:From: Tom LaneDate: 2012-08-15 04:15:22
Subject: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav

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