| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us>, Arthur Silva <arthurprs(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fixed xloginsert_locks for 9.4 |
| Date: | 2014-10-03 18:49:14 |
| Message-ID: | 542EEFAA.9080003@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-10-03 19:20:37 | Re: Fixed xloginsert_locks for 9.4 |
| Previous Message | Bruce Momjian | 2014-10-03 18:42:29 | Re: Fixed xloginsert_locks for 9.4 |