Re: Overhauling GUCS

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