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