Re: improvements to pgtune

> Every time I've gotten pulled into discussions of setting parameters 
> based on live monitoring, it's turned into a giant black hole--absorbs a 
> lot of energy, nothing useful escapes from it.  I credit completely 
> ignoring that idea altogether, and using the simplest possible static 
> settings instead, as one reason I managed to ship code here that people 
> find useful.  I'm not closed to the idea, just not optimistic it will 
> lead anywhere useful.  That makes it hard to work on when there are so 
> many obvious things guaranteed to improve the program that could be done 
> instead.

What would you list as the main things pgtune doesn't cover right now?  I have my own list, but I suspect that yours is somewhat different.

I do think that autotuning based on interrogating the database is possible.  However, I think the way to make it not be a tar baby is to tackle it one setting at a time, and start with ones we have the most information for.  One of the real challenges there is that some data can be gleaned from pg_* views, but a *lot* of useful performance data only shows up in the activity log, and then only if certain settings are enabled.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco