Re: Overhauling GUCS

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Michael Nacos <m(dot)nacos(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Overhauling GUCS
Date: 2008-08-17 20:48:20
Message-ID: Pine.GSO.4.64.0808171610220.22642@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2008-08-17 21:14:19 Re: API for Managing pg_hba and postgresql.conf
Previous Message Greg Smith 2008-08-17 20:07:53 Re: pgbench duration option