> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
