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+JU+NC62WT=pQOS=LFaD0_YAsERp8VThNUNzt4y0pexmw@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 3:46 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
It would seem preferable to call the lack of auto-analyzing after these operations a bug and back-patch a fix that injects an analyze side-effect just before their completion.  It doesn't have to be smart either, analyzing things even if the created (or newly validated) index doesn't have statistics of its own isn't a problem in my book.

+1 to consider it as a major problem of CREATE INDEX [CONCURRENTLY] for indexes on expressions, it's very easy to forget what I've observed many times.

Although, this triggers a question – should ANALYZE be automated in, say, pg_restore as well?

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)?

Thanks,
Nik

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: PATCH: Report libpq version and configuration
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Add important info about ANALYZE after create Functional Index