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