On Fri, Oct 3, 2014 at 2:20 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Oct 3, 2014 at 2:49 PM, Heikki Linnakangas > <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
