Re: Fixed xloginsert_locks for 9.4
| От | Mark Kirkwood |
|---|---|
| Тема | Re: Fixed xloginsert_locks for 9.4 |
| Дата | |
| Msg-id | 542F4C07.3080000@catalyst.net.nz обсуждение исходный текст |
| Ответ на | Re: Fixed xloginsert_locks for 9.4 (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
On 04/10/14 12:10, Bruce Momjian wrote: > On Sat, Oct 4, 2014 at 12:00:36PM +1300, Mark Kirkwood wrote: >>> I don't think we can offer absolutely accurate tuning advice, but I'm >>> sure we can give some guidance. Let me try. >>> >> >> +1 >> >> I think it is ok to document our reason for providing the new GUC - >> along with that fact that it is a new one and we need more field >> testing and benchmarks to provide comprehensive advice about how to >> set - and recommend leaving it alone unless consult with >> experts/this list etc. > > I predict that such a setting will remain in postgresql.conf for years > with almost zero activity, as have other similar efforts. > Sure that *may* happen. In fact in my experience the vast majority of our current GUCs are never altered in the field - however when you run into a situation where a certain GUC solves your performance issue, then that seldom used GUC really gets some love. So altho I get your point about endless proliferation of 'em not being cost free, I'd like to plug the other side of the argument too - having the flexibility to adjust your Postgres installation to work well with <random platform with annoying quirks> is the corresponding benefit. In addition with the increasing use of cloud platforms - the situation above is likely to become *more* common (Postgres in Openstack using Ceph for volume storage is a case in point). Cheers Mark
В списке pgsql-hackers по дате отправления: