On Mon, Oct 26, 2020 at 3:46 PM David G. Johnston < david.g.johns...@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
