Re: Add important info about ANALYZE after create Functional Index

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, 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-28 19:35:46
Message-ID: 20201028193546.ayzxua26od3qnbzt@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 28, 2020 at 03:18:52PM -0400, Tom Lane wrote:
>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote:
>>> Given how simple the manual workaround is not having it be manual seems
>>> like it would be safe and straight-forward to implement.
>
>> Maybe, but I wouldn't be surprised if it was actually a bit trickier in
>> practice, particularly for the CONCURRENTLY case. But I haven't tried.
>
>> Anyway, I think there's an agreement it'd be valuable to do this after
>> CREATE INDEX in the future, so if someone wants to implement it that'd
>> be great. We can consider backpatching only once we have an actual patch
>> anyway.
>
>Just to be clear, I'm entirely *not* on board with that. IMV it's
>intentional that we do not force auto-analyze activity after CREATE
>INDEX or CREATE STATISTICS. If we change that, people will want a
>way to opt out of it, and then your "simple" patch isn't so simple
>anymore.

True. Some users may have reasons to not want the analyze, I guess.

> (Not that it was simple anyway. What if the CREATE is
>inside a transaction block, for instance? There's no use in
>kicking autovacuum before commit.)
>

I don't think anyone proposed to do this through autovacuum. There was a
reference to auto-analyze but I think that was meant as 'run analyze
automatically.' Which would work in transactions just fine, I think.

But I agree it'd likely be a more complicated patch than it might seem
at first glance.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-10-28 19:36:06 Re: duplicate function oid symbols
Previous Message Justin Pryzby 2020-10-28 19:34:02 Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)