DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
	:content-type:references;
	b=ekkJfdXpb0vCWlVZY8AYN0MRbsRdI1L1SWmy6j6DK/BVOEUBB8veyA/7ZMHvMEAZ8o
	QboVw2TdwwKLLDyPOAEm/+W9023J9tAnArd5smOAEM8DIEBxXLBD1JsL7VuEkwyzOyBN
	d1pF1fWAz3Vr3sgcLxIOnSRR4f0+RgCxgDBcs=
Message-ID: <407fa4640808180426q26a41cv817deb91dbbcd312@mail.gmail.com>
Date: Mon, 18 Aug 2008 12:26:26 +0100
From: "Michael Nacos" <m.nacos@gmail.com>
To: "Greg Smith" <gsmith@gregsmith.com>, bruce@momjian.us
Subject: Re: Overhauling GUCS
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <Pine.GSO.4.64.0808171610220.22642@westnet.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_22374_10211890.1219058786466"
References: <7473.1212625397@sss.pgh.pa.us>
	<200807161530.m6GFUNY28751@momjian.us>
	<407fa4640808130738s3537ca45j22322a5eb70f9173@mail.gmail.com>
	<Pine.GSO.4.64.0808171610220.22642@westnet.com>

------=_Part_22374_10211890.1219058786466
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

What I'm interested in is auto-tuning, not necessarily overhauling GUCS,
which happens to be the subject of this thread :-)
Having done a SELECT * FROM pg_settings, all the information you need seems
to be there...
Maybe I'm being over-simplistic here, but the important bit is knowing how
you should tune stuff - and this is what I'm hoping to learn through this
process.
Now, you could probably sidestep UI and GUCS concerns by moving the
auto-tuning process inside the database. You don't need fancy GUIs for
guessing configuration parameters, and if you can already do that, coming up
with a GUI should be pretty straightforward.
For example, I see no reason why you couldn't capture the logic of tuning in
a couple of PL/Python functions to look up usage stats, size of indices etc.
PL/Python being an "untrusted" language, you could even write a new
postgresql.conf file to disk, with the suggested alterations. Cheap, quick
and cheerful!

Perhaps the auto-tuning conversation should take place in a separate thread,
how do you feel about changing the subject line? The most insteresting bit
is discussing and testing tuning strategies. This, of course, is related to
the [admin] and [perform] side of things, but there is also a development
dimension. As soon as there is a tuning strategy published, a number of
tools will certainly follow.

Michael

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.
>
>

------=_Part_22374_10211890.1219058786466
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">What I&#39;m interested in is auto-tuning, not necessarily overhauling GUCS, which happens to be the subject of this thread :-)<br>Having done a SELECT * FROM pg_settings, all the information you need seems to be there...<br>
Maybe I&#39;m being over-simplistic here, but the important bit is knowing how you should tune stuff - and this is what I&#39;m hoping to learn through this process.<br>Now, you could probably sidestep UI and GUCS concerns by moving the auto-tuning process inside the database. You don&#39;t need fancy GUIs for guessing configuration parameters, and if you can already do that, coming up with a GUI should be pretty straightforward.<br>
For example, I see no reason why you couldn&#39;t capture the logic of tuning in a couple of PL/Python functions to look up usage stats, size of indices etc. PL/Python being an &quot;untrusted&quot; language, you could even write a new postgresql.conf file to disk, with the suggested alterations. Cheap, quick and cheerful!<br>
<br>Perhaps the auto-tuning conversation should take place in a separate thread, how do you feel about changing the subject line? The most insteresting bit is discussing and testing tuning strategies. This, of course, is related to the [admin] and [perform] side of things, but there is also a development dimension. As soon as there is a tuning strategy published, a number of tools will certainly follow.<br>
<br>Michael<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes, there&#39;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&#39;ve been beating that drum for a while now. &nbsp;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. &nbsp;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.<br>
<font color="#888888">
<br>
</font></blockquote></div><br></div>

------=_Part_22374_10211890.1219058786466--