Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb
Дата
Msg-id 7737.1389238346@sss.pgh.pa.us
обсуждение исходный текст
Ответ на integrate pg_upgrade analyze_new_cluster.sh into vacuumdb  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Peter Eisentraut <peter_e@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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Add CREATE support to event triggers
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier