On Fri, Oct 3, 2014 at 2:20 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 3, 2014 at 2:49 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> I stand by my decision to make it a #define, at least until someone voices
>> their objection in the form of a documentation patch.
>
> I think that's exactly right. If we knew users should tune this, then
> we might be able to make it self-tuning, which would be best of all.
> At the least, we'd have useful information to provide to people who
> want to change it. However, if we *can't* provide tuning advice, then
> all making it a GUC does is give users a knob that says "turning this
> might make things better! or worse!". Adding such knobs does little
> harm individually, but in the aggregate it makes for a product that is
> mysterious, hard to use, and hard to maintain and improve.
100% agree. It's a very simple standard: if you provide a performance
affecting GUC pleease provide guidelines to end user regarding the
tradeoffs or performance interactions being managed. Failure to do
this causes an interesting problem; let's take the case of shared
buffers for example which isn't explained very well. Failure to
properly document or explain the interactions causes the user to make
invalid assumptions about the setting (more memory = faster!) or take
obsolete advice (Tom Lane said in 1997 that 128mb is about right) as
gospel. This has been a long running gripe of mine.
merlin