pgtune: postgresql.conf wizard - Mailing list pgsql-hackers

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@gregsmith.com http://www.gregsmith.com Baltimore, MD