Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > On 2025-Aug-16, Robert Treat wrote: > > > On Tue, Aug 5, 2025 at 4:59 AM Antonin Houska <a...@cybertec.at> wrote: > > > > Now that we want to cover the CLUSTER/VACUUM FULL completely, I've > > > checked the > > > options of VACUUM FULL. I found two items not supported by REPACK (but > > > also > > > not supported by by CLUSTER): ANALYZE and SKIP_DATABASE_STATS. Maybe just > > > let's mention that in the user documentation of REPACK? > > > > I would note that both pg_repack and pg_squeeze analyze by default, > > and running "vacuum full analyze" is the recommended behavior, so not > > having analyze included is a step backwards. > > Make sense to add ANALYZE as an option to repack, yeah. > > So if I repack a single table with > REPACK (ANALYZE) table USING INDEX; > > then do you expect that this would first cluster the table under > AccessExclusiveLock, then release the lock to do the analyze step, or > would the analyze be done under the same lock? This is significant for > a query that starts while repack is running, because if we release the > AEL then the query is planned when there are no stats for the table, > which might be bad. > > I think the time to run the analyze step should be considerable shorter > than the time to run the repacking step, so running both together under > the same lock should be okay.
AFAICS, VACUUM FULL first releases the AEL, then it analyzes the table. If users did not complain so far, I'd assume that vacuum_rel() (effectively cluster_rel() in the FULL case) does not change the stats that much. -- Antonin Houska Web: https://www.cybertec-postgresql.com
