Re: Add important info about ANALYZE after create Functional Index

From: Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(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 04:44:42
Message-ID: CANNMO++HMxe6=F=vBuUUntuwXaB2kPxxsq3XrvCm1Ni596Yhtg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 26, 2020 at 7:03 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> 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.
>

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2020-10-27 04:49:37 Re: PATCH: Report libpq version and configuration
Previous Message Amit Kapila 2020-10-27 03:47:43 Re: Resetting spilled txn statistics in pg_stat_replication