pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Smith <gsmith@gregsmith.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers@postgresql.org, Josh Berkus <josh@agliodbs.com>
Subject: Re: Overhauling GUCS
Date: Wed, 11 Jun 2008 21:46:33 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0806112127170.13925@westnet.com> (raw)
In-Reply-To: <25534.1213232184@sss.pgh.pa.us>
References: <200806112340.m5BNea602628@momjian.us>
	<25534.1213232184@sss.pgh.pa.us>

On Wed, 11 Jun 2008, Tom Lane wrote:

> Who said anything about loops?  What I am talking about is what happens
> during
> 	set memory_usage = X;  // implicitly sets work_mem = X/100, say
> 	set work_mem = Y;
> 	set memory_usage = Z;
> What is work_mem now, and what's your excuse for saying so, and how
> will you document the behavior so that users can understand it?
> (Just to make things interesting, assume that some of the above SETs
> happen via changing postgresql.conf rather than directly.)

People are already exposed to issues in this area via things like the 
include file mechanism.  You can think of that two ways.  You can say, 
"there's already problems like this so who cares if there's another one". 
Or, you can say "let's not add even more confusion like that".

Having a mini programming language for setting parameters is interesting 
and all, and it might be enough to do a good job of handling the basic 
newbie setup chores.  But I don't think it's a complete solution and 
therefore I find moving in that direction a bit of a distraction; your 
concerns about ambiguity just amplify that feeling.  It's unlikely that 
will get powerful enough to enable the "one true config file" that just 
works for everybody.  There's too many things that depend a bit on both 
data access pattern and on overall database size/structure no matter what 
you do.

[If only there were some technology that did workload profiling and set 
the server parameters based on that.  Some sort of dynamic tuning tool; 
wouldn't that be great?  Oh well, that's just a dream right now I guess.]

I'm not sure if I've stated this explicitly yet, but I personally have no 
interest in just solving the newbie problem.  I want a tool to help out 
tuning medium to large installs, and generating a simple config file is 
absolutely something that should come out of that as a bonus.  Anything 
that just targets the simple installs, though, I'm not very motivated to 
chase after.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD



view thread (226+ messages)  latest in thread

Message-ID: <Pine.GSO.4.64.0806112127170.13925@westnet.com>
Permalink:  ../Pine.GSO.4.64.0806112127170.13925@westnet.com/
Also on:    postgresql.org/message-id/Pine.GSO.4.64.0806112127170.13925@westnet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: gsmith@gregsmith.com, tgl@sss.pgh.pa.us, bruce@momjian.us, josh@agliodbs.com
  Subject: Re: Overhauling GUCS
  In-Reply-To: <Pine.GSO.4.64.0806112127170.13925@westnet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox