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
|
| Список | 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 по дате отправления: