pgtune: postgresql.conf wizard

pgtune is now on pgFoundry: http://pgfoundry.org/projects/pgtune/
I just released an update to there, and attached here for the archives is
that same code.

Progress since the last code drop to this list:

-All of the necessary integer handling needed was extracted from guc.c and
implemented, in particular memory unit handling that matches the server
for input and SHOW-style output. One feature that's already allowed is it
can sort out:

Input: shared_buffers='32768'
tuned: shared_buffers='256MB'

Notice those are the same value, and then not do anything to that setting.
This will make round trips through pgtune much less disruptive. And all
it should take to eventually add 8.1 compatibility (before memory units
like kB worked) is turning off my SHOW-style implementation and just
working with the integer values.
-Lots of code cleanup based on all the hiccups reported back to me

Primary open issues at this point:
-Update the model to limit shared memory use on Windows
-Degrade more gracefully on low memory systems
-Optional module to estimate shared memory use and output sysctl
suggestions

The next time I get a block of time to work on this I'll swat all those,
getting past all the memory unit stuff was the main thing I've been stuck
on recently. There are a few TODO items tagged in the code to finish
cleaning up too. I'm on track to have everything I wanted in a 1.0 (only
targeting 8.4) ready by Feb 1 in time for beta.

Things I was hoping for some input on:
-Using default_stats_target=100 doesn't seem controversial anymore, which
makes we wonder if it makes sense to restore the original DW suggestion of
400 Josh suggested?
-There was some talk about making constraint_exclusion have an additional
smart mode aimed at inheritance. Not sure where that's at, but it would
impact the model were it available.

I also made a number of Python style improvements based on review from
Nathan. If you're not interested in that topic you should certainly stop
reading here as that's all I cover below.

On Fri, 5 Dec 2008, Nathan Boley wrote:

> - The windows specific try block ( line 16 ) raises a ValueError...

I rewrote that whole mess based on all the feedback I got and I hope this
interface is much more robust.

> - from ctypes import * ( 18 ) makes the block difficult to read and
> pollutes the namespace.

Noted, will try to reduce what it calls when I do my final Windows
testing. Am not sure exactly what it needs so I won't know if I broke it
trying to reduce the import use until then.

> - all classes ( 58, 135, 205 ) are 'old-style' classes.

Converted to new style ones.

> - The doc strings ( 59, 136, 206 ) don't follow standard conventions,
> described here http://www.python.org/dev/peps/pep-0257/.

Improved doc strings are on my list for later cleanup, haven't gotten to
it yet.

> - Tuple unpacking doesn't require the tuple boundaries ( 446 and
> others ). ie, options, args = ReadOptions() works.

Fixed a bunch of those, if you notice any I missed please point them out.

> overloading __str__ and __repr__ are the python ways to return string
> representations of an object

Converted my toString call to use __str__ and str().

> Have you considered the use of properties
> http://www.python.org/download/releases/2.2.3/descrintro/#property ?

I wasn't fully aware of properties before. Now that I am, I find I
dislike them. For this type of app, there doesn't seem to be much benefit
for the extra code I'd put in.

The main reason I provided those getter functions rather than having
things directly reference the object's fields was so I could change the
underlying implementation without breaking the API. I didn't really care
about making things private. I now realize that I can change the API and
make the caller still think they're directly accessing the field with
properties, so I just made most things pull right from the fields now.
That cut out some code that was only supporting that poor data hiding.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD