On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Eisentraut <pete...@gmx.net> writes: >> pg_upgrade creates a script analyze_new_cluster.{sh|bat} that runs >> vacuumdb --analyze-only in three stages with different statistics target >> settings to get a fresh cluster analyzed faster. I think this behavior >> is also useful for clusters or databases freshly created by pg_restore >> or any other loading mechanism, so it's suboptimal to have this >> constrained to pg_upgrade. > >> Therefore, I suggest to add this functionality into the vacuumdb >> program. > > Seems reasonable. > >> There are some details to be considered about who pg_upgrade would call >> this. For example, would we keep creating the script and just have the >> script call vacuumdb with the new option, or would we skip the script >> altogether and just print a message from pg_upgrade? Also, pg_upgrade >> contains logic to run a vacuum (not only analyze) in the final run when >> upgrading from PostgreSQL <8.4 to deal with the freespace map. Not sure >> how to adapt that; maybe just keep the script and run a non-analyze >> vacuum after the analyze. > > I don't think this vacuumdb feature should deal with any > version-conversion issues. So it sounds like the thing to do is keep the > wrapper script, which will give us a place to put any such special actions > without having to kluge up vacuumdb's behavior. That'll avoid breaking > scripts that users might've built for using pg_upgrade, too.
I guess I don't see what's wrong with kludging up vacuumdb. It's not like that's a very complicated utility; what will be hurt by a few more options? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers