Re: Fixed xloginsert_locks for 9.4
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Fixed xloginsert_locks for 9.4 |
| Дата | |
| Msg-id | 542EEFAA.9080003@vmware.com обсуждение исходный текст |
| Ответ на | Re: Fixed xloginsert_locks for 9.4 (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: Fixed xloginsert_locks for 9.4
|
| Список | pgsql-hackers |
On 10/03/2014 09:42 PM, Bruce Momjian wrote: > On Fri, Oct 3, 2014 at 03:30:35PM -0300, Arthur Silva wrote: >> > Every GUC add complexity to the system because people have to understand >> > it to know if they should tune it. No GUC is zero-cost. >> >> Please see my blog post about the cost of adding GUCs: >> >> http://momjian.us/main/blogs/pgblog/2009.html#January_10_2009 >> >> That's true Bruce (nice post, it was a good reading). >> But how can we ignore 25%+ improvements (from 8 to 24)? >> At very least we should delivery some pretty good defaults. > > Well, checkpoint_segments was a similar case where we couldn't give good > tuning advice so we went with a server log file warning if it needed to > be increased --- this might be a similar case. I have no idea how to decide at runtime whether it should be increased or not. If that was feasible, we probably could make it tune itself on the fly - it's not like checkpoint_segments where you need more disk space if you increase it. I stand by my decision to make it a #define, at least until someone voices their objection in the form of a documentation patch. - Heikki
В списке pgsql-hackers по дате отправления: