Re: Add important info about ANALYZE after create Functional Index
От | Tomas Vondra |
---|---|
Тема | Re: Add important info about ANALYZE after create Functional Index |
Дата | |
Msg-id | 20201028193546.ayzxua26od3qnbzt@development обсуждение исходный текст |
Ответ на | Re: Add important info about ANALYZE after create Functional Index (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add important info about ANALYZE after create Functional Index
|
Список | 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 по дате отправления: