On 15 August 2012 05:15, Tom Lane <[email protected]> wrote: > Peter Geoghegan <[email protected]> writes: >> On 14 August 2012 21:26, Bruce Momjian <[email protected]> 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 -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
