Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Adding REPACK [concurrently]
Date
Msg-id 202508191222.ghumvyzw4cmj@alvherre.pgsql
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Robert Treat <rob@xzilla.net>)
Responses Re: Adding REPACK [concurrently]
List pgsql-hackers
On 2025-Aug-16, Robert Treat wrote:

> On Tue, Aug 5, 2025 at 4:59 AM Antonin Houska <ah@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.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Computing is too important to be left to men." (Karen Spärck Jones)



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Enable data checksums by default
Next
From: Alvaro Herrera
Date:
Subject: Re: Adding REPACK [concurrently]