On 15 August 2012 05:15, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <pe...@2ndquadrant.com> writes: >> On 14 August 2012 21:26, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
