On Sat, May 23, 2009 at 10:31 PM, decibel <decibel@decibel.org> wrote:
> One of the talks at PGCon (update in place?) recommended running vacuumdb -z
> to analyze all tables to rebuild statistics. Problem with that is it also
> vacuums everything. ISTM it'd be useful to be able to just vacuum all
> databases in a cluster, so I hacked it into vacuumdb.
I think you meant "ISTM it'd be useful to be able to just analyze all
databases in a cluster".
> Of course, using a command called vacuumdb is rather silly, but I don't see
> a reasonable way to deal with that. I did change the name of the functions
> from vacuum_* to process_*, since they can vacuum and/or analyze.
>
> The only thing I see missing is the checks for invalid combinations of
> options, which I'm thinking should go in the function rather than in the
> option parsing section. But I didn't want to put any more effort into this
> if it's not something we actually want.
It does seem somewhat useful to be able to analyze all databases
easily from the command-line, but putting it into vacuumdb is
certainly a hack. (By the way, we don't allow C++ style comments.)
I wonder if we ought not to find a way to make pg_migrator
automatically do some of these things after starting up the database.
Given autovacuum, it should be a pretty rare thing to need to manually
analyze every database in the cluster, so instead of building a
general tool to do this, it might make more sense to make it happen
automatically in the one case where we know it's necessary.
I noticed in Bruce's talk that there are a number of post-migration
steps which are currently partially manual. Ideally we'd like to
automate them all, preferably in some sort of well-thought-out order.
I actually suspect this is something like: analyze each database,
reindex those indices invalidated by the upgrade, analyze each
database again. Ideally we'd like to have some control over the
degree of parallelism here too but that might be asking too much for
8.4.
...Robert
