Re: Add important info about ANALYZE after create Functional Index

Поиск
Список
Период
Сортировка
От Nikolay Samokhvalov
Тема Re: Add important info about ANALYZE after create Functional Index
Дата
Msg-id CANNMO++HMxe6=F=vBuUUntuwXaB2kPxxsq3XrvCm1Ni596Yhtg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add important info about ANALYZE after create Functional Index  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Add important info about ANALYZE after create Functional Index  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Mon, Oct 26, 2020 at 7:03 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Monday, October 26, 2020, Nikolay Samokhvalov <samokhvalov@gmail.com> wrote:
Although, this triggers a question – should ANALYZE be automated in, say, pg_restore as well?

Independent concern.

It's the same class of issues – after we created some objects, we lack statistics and willing to automate its collection. If the approach is automated in one case, it should be automated in the others, for consistency.

And another question: how ANALYZE needs to be run? If it's under the user's control, there is an option to use vacuumdb --analyze and benefit from using -j to parallelize the work (and, in some cases, benefit from using --analyze-in-stages). If we had ANALYZE as a part of building indexes on expressions, should it be parallelized to the same extent as index creation (controlled by max_parallel_maintenance_workers)?

None of that seems relevant here.  The only relevant parameter I see is what to specify for “table_and_columns”.

I'm not sure I follow.

Thanks,
Nik

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Resetting spilled txn statistics in pg_stat_replication
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: PATCH: Report libpq version and configuration