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
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_*) |