Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
От | Peter Geoghegan |
---|---|
Тема | Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav |
Дата | |
Msg-id | CAEYLb_WNUODiZqUW2bTm_kWOoV4GJS64e2iAyoJvT2_kjDtnEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Re: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav |
Список | pgsql-hackers |
On 15 August 2012 14:39, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If you wanted to re-implement all the guc.c logic for supporting > unit-ified values such that it would also work with floats, we could > do that. It seems like way more mechanism than the problem is worth > however. Fair enough. I'm not quite comfortable recommending a switch to milliseconds if that implies a loss of sub-millisecond granularity. I know that someone is going to point out that in some particularly benchmark, they can get another relatively modest increase in throughput (perhaps 2%-3%) by splitting the difference between two adjoining millisecond integer values. In that scenario, I'd be tempted to point out that that increase is quite unlikely to carry over to real-world benefits, because the setting is then right on the cusp of where increasing commit_delay stops helping throughput and starts hurting it. The improvement is likely to get lost in the noise in the context of a real-world application, where for example the actually cost of an fsync is more variable. I'm just not sure that that's the right attitude. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: