From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jd(at)commandprompt(dot)com |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Jacky Leng <lengjianquan(at)163(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Has anybody think about changing BLCKSZ to an option of initdb? |
Date: | 2009-03-14 16:25:23 |
Message-ID: | 5265.1237047923@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> On Sat, 2009-03-14 at 11:47 -0400, Tom Lane wrote:
>> ... Aside from the implementation costs of making
>> it variable, there is the oft repeated refrain that Postgres has too
>> many configuration knobs already.
> Well that "too many knobs" argument doesn't apply to this scenario etc.
> Anyone who is making use of these need those knobs.
That's nonsense --- on that argument, any variable no matter how obscure
should be exposed as a tunable because there might be somebody somewhere
who could benefit from it. You are ignoring the costs to everybody else
who don't need it, but still have to study a GUC variable definition and
try to figure out whether it needs changing for their usage. Not to
mention the people who set it to a bad value and suffer lost performance
as a result (cf vacuum_cost_delay).
Note that I am not saying "no", I am saying "give us some evidence
*first*". The costs in implementation effort and user confusion are
certain, the benefits are not.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-03-14 17:39:35 | Over-rigidity in recent to_timestamp() rewrite |
Previous Message | Joshua D. Drake | 2009-03-14 15:51:17 | Re: Has anybody think about changing BLCKSZ to an option of initdb? |