Thread: 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(-)
Re: pgsql: Revert "commit_delay" change; just add comment that we don't hav
From
Peter Geoghegan
Date:
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
Re: pgsql: Revert "commit_delay" change; just add comment that we don't hav
From
Peter Geoghegan
Date:
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