> So everything you mentioned is either recently added/documented or being
> actively worked on somewhere, and the first two were things I worked on
> myself after noticing they were missing. Believe me, I feel the items
> that still aren't there, but they're moving along at their own pace.
> There's already more tuning knowledge available than tools to help apply
> that knowledge to other people's systems, which is why I think a diversion
> to focus just on that part is so necessary.
But as an administrator/developer, I don't understand the focus on a new
API for "writing my config" for me... I'ld love a tool that helped me
"analyze" my current running PG database (and yes, that includes getting
*current* settings), and "suggest" config changes, ideally in order that
the tool thinks will make a difference... I can make that change, and
distribute it. That's the easy part. If I really trust the tool then
I'll just blindly run it (depending on it's output format):
$TOOL > $PGDATA/postgresql.conf
in which case, I don't care if it groked any of my previous comments and
cruft. Otherwise, I'll look at it, and integrate some (or all) of the
changes into postgresql.conf using my preferred method of
commenting/SCM/quirks.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/
work like a slave.
No comments:
Post a Comment