| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
| Cc: | Fabrízio Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add important info about ANALYZE after create Functional Index |
| Date: | 2020-10-27 02:03:54 |
| Message-ID: | CAKFQuwY8gn0kLB-=hOxwUtkvFQTSeL1QQ0LN1vEdpevMn6MUww@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Monday, October 26, 2020, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
wrote:
>
>
> Although, this triggers a question – should ANALYZE be automated in, say,
> pg_restore as well?
>
Independent concern.
>
> 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”.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2020-10-27 02:11:25 | Re: Commitfest 2020-11 |
| Previous Message | Nikolay Samokhvalov | 2020-10-27 01:29:07 | Re: Add important info about ANALYZE after create Functional Index |