Обсуждение: pgsql: Revert "commit_delay" change; just add comment that we don't hav

Revert "commit_delay" change; just add comment that we don't have
a microsecond specification.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/03bda4535ee119d3dae7226faebed089925ace7e

Modified Files
--------------
src/backend/utils/misc/guc.c |    4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

On 14 August 2012 21:26, Bruce Momjian <bruce@momjian.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. After all, we've already been switching to milliseconds
across various statistics views, including pg_stat_statements.

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

Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 14 August 2012 21:26, Bruce Momjian <bruce@momjian.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?

            regards, tom lane

On 15 August 2012 05:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <peter@2ndquadrant.com> writes:
>> On 14 August 2012 21:26, Bruce Momjian <bruce@momjian.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