Re: analyze after a database restore?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: analyze after a database restore?
Дата
Msg-id 27615.1046376756@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: analyze after a database restore?  (mlw <pgsql@mohawksoft.com>)
Ответы Re: analyze after a database restore?
Re: analyze after a database restore?
Re: analyze after a database restore?
Список pgsql-hackers
mlw <pgsql@mohawksoft.com> writes:
>  From an "ease of use" perspective, it would be one less step.

There is something to be said for that.  As Rod notes, this has been
considered and rejected before --- but I think that was back when
ANALYZE (a) could only be done as part of VACUUM, and (b) insisted on
scanning the whole table.  The current implementation is vastly
lighter-weight than what we were looking at back then.  Perhaps it's
time to reconsider.

Although I suggested doing a single unconditional ANALYZE at the end
of the script, second thought leads me to think the per-table ANALYZE
(probably issued right after the table's data-load step) might be
better.  That way you'd not have any side-effects on already-existing
tables in the database you are loading to.  OTOH, that way would leave
the system catalogs un-analyzed, which might be bad.
        regards, tom lane


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

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: Can pessimistic locking be emulated?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Free-space-map management thoughts