Re: Overhauling GUCS - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Overhauling GUCS
Date
Msg-id Pine.GSO.4.64.0808171610220.22642@westnet.com
Whole thread Raw
In response to Re: Overhauling GUCS  ("Michael Nacos" <m.nacos@gmail.com>)
Responses Re: Overhauling GUCS  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Overhauling GUCS  (Steve Atkins <steve@blighty.com>)
Re: Overhauling GUCS  ("Michael Nacos" <m.nacos@gmail.com>)
List pgsql-hackers
On Wed, 13 Aug 2008, Michael Nacos wrote:

> Hi there... Configuration autotuning is something I am really interested in.
> I have seen this page: http://wiki.postgresql.org/wiki/GUCS_Overhaul and
> a couple of emails mentioning this, so I wanted to ask is someone already
> on it? If yes, I'd like to contribute.

Good time to give a status report on what's been going on with all this.

With some help I just finished off an answer to problem #1 there recently, 
"Most people have no idea how to set these".  There was some concern here 
that work was being done on config tools without a clear vision of what 
was going to be tuned.  See 
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server for an intro 
on how to set the 18 most important parameters (+7 logging parameters) 
based on the best information I'm aware of.

Circa June, Steve Atkins was looking into writing a C++/Qt GUI tuning 
interface application, with the idea that somebody else would figure out 
the actual smarts to the tuning effort.  Don't know where that's at.

Josh Berkus and I have been exchanging some ideas for the GUC internals 
overhaul and had a quick discussion about that in person last month. 
We've been gravitating toward putting all the extra information we'd like 
to push into there in an extra catalog table (pg_settings_info or 
something).  The stuff the server needs to start can stay right where it 
is right now, all the other decoration can move to the table.

> Ideally, an external little app should also provide recommendations based
> on current database usage statistics -- wouldn't this constitute something
> akin to application-specific advice?

Yes, there's a grand plan for a super-wizard that queries the database for 
size, index, and statistics information for figure out what to do; I've 
been beating that drum for a while now.  Unfortunately, the actual 
implementation is blocked behind the dreadfully boring work of sorting out 
how to organize and manage the GUC information a bit better, and the 
moderately boring work of building a UI for modifying things.  If you were 
hoping to work on the sexy autotuning parts without doing some of the 
grunt work, let me know if you can figure out how so I can follow you.

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


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: pgbench duration option
Next
From: Greg Smith
Date:
Subject: Re: API for Managing pg_hba and postgresql.conf