Re: Add important info about ANALYZE after create Functional Index - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Add important info about ANALYZE after create Functional Index
Date
Msg-id 20201028193546.ayzxua26od3qnbzt@development
Whole thread Raw
In response to Re: Add important info about ANALYZE after create Functional Index  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add important info about ANALYZE after create Functional Index
List pgsql-hackers
On Wed, Oct 28, 2020 at 03:18:52PM -0400, Tom Lane wrote:
>Tomas Vondra <tomas.vondra@2ndquadrant.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 



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)
Next
From: Tom Lane
Date:
Subject: Re: duplicate function oid symbols