Re: pg_migrator to /contrib in a later 9.0 beta

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_migrator to /contrib in a later 9.0 beta
Дата
Msg-id 16043.1273155545@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_migrator to /contrib in a later 9.0 beta  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: pg_migrator to /contrib in a later 9.0 beta  (Bruce Momjian <bruce@momjian.us>)
Re: pg_migrator to /contrib in a later 9.0 beta  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Jesper Krogh wrote:
>> I should have written:
>> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
>> itself?

> Yeah, the statistics are part of the system tables, and system tables
> are fully handled by pg_dumpall --schema-only (except for statistics). 
> There might be changes in the system table statistics format that would
> break if pg_migrator tried to migrate the statistics.

Right, it's not really practical for pg_migrator to just copy over the
statistics without any intelligence.  We might at some time choose to
teach it which stats could be copied safely, but that hardly seems like
something to do in version 1.0 --- and anyway it could not be a 100%
solution.

> And if pg_migrator ran analyze itself, it would greatly increase its
> great migration times!

Exactly.  It's not a win for pg_migrator to not give you back control of
the database until everything has been ANALYZEd.  That's a task that can
likely be done in background.
        regards, tom lane


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

Предыдущее
От: Mike Fowler
Дата:
Сообщение: Adding xpath_exists function
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: max_standby_delay considered harmful