Re: Has anybody think about changing BLCKSZ to an option of initdb?

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 21:17:27
Message-ID: 1237065447.15092.1.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2009-03-14 at 12:25 -0400, Tom Lane wrote:
> "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).

I think you misunderstood me. I wasn't actually arguing for the
variable. I was arguing that if the variable was required that those are
the people that would need it. I frankly don't see a need for this
variable but again, I think that the performance lab would be provide
the information we need to make such a determination.

> 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.

I do not disagree with this.

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2009-03-15 02:00:07 Re: Over-rigidity in recent to_timestamp() rewrite
Previous Message Andrew Gierth 2009-03-14 20:49:52 hstore patch, part 1