Re: why there is not VACUUM FULL CONCURRENTLY? - Mailing list pgsql-hackers

From Marcos Pegoraro
Subject Re: why there is not VACUUM FULL CONCURRENTLY?
Date
Msg-id CAB-JLwYSy+oquVkiwubhqs-rHfjvF6p5PRmQHRg4_1vtaL_E7A@mail.gmail.com
Whole thread Raw
In response to Re: why there is not VACUUM FULL CONCURRENTLY?  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
You mentioned fillfactor only on cluster notes, would be good to mention it on refsynopsisdiv, I think.

+  <para>
+   <command>REPACK</command> reclaims storage occupied by dead
+   tuples. Unlike <command>VACUUM</command>, it does so by rewriting the
+   entire contents of the table specified
+   by <replaceable class="parameter">table_name</replaceable> into a new disk

-   file with no extra space, allowing unused space to be returned to the
+   file with no extra space, obeying fillfactor settings, allowing unused space to be returned to the  

+   operating
+   system.
+  </para>


regards
Marcos


Em qua., 19 de fev. de 2025 às 14:08, Antonin Houska <ah@cybertec.at> escreveu:
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> On 2025-Jan-30, Michael Banck wrote:
>
> > > I haven't addressed the problem of a new command yet - for that I'd like to
> > > see some sort of consensus, so that I do not have to do all the related
> > > changes many times.
> >
> > Well, looks like this patch-set is blocked on the bikeshedding part?
> >
> > Somebody should call a shot here, then.
>
> A bunch of people discussed this patch in today's developer meeting in
> Brussels.  There's pretty much a consensus on using the verb REPACK
> CONCURRENTLY for this new command -- where unadorned REPACK would be
> VACUUM FULL, and we'd have something like REPACK WITH INDEX or maybe
> REPACK USING INDEX to take the CLUSTER place.

This is a patch that adds the REPACK command (w/o CONCURRENTLY). I'll
incorporate it into the patch series but it'd be great if this part was a
little bit stable before I start to rebase the depending patches. Thanks.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com


--

*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer den
bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat
dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte,
dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder
Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich
in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.

*CONFIDENTIALITY NOTICE & DISCLAIMER
*This message and any attachment are
confidential and may be privileged or otherwise protected from disclosure
and solely for the use of the person(s) or entity to whom it is intended.
If you have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this message and
any attachment from your system. If you are not the intended recipient, be
advised that any use of this message is prohibited and may be unlawful, and
you must not copy this message or attachment or disclose the contents to
any other person.

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Fix logging for invalid recovery timeline
Next
From: Andres Freund
Date:
Subject: Re: BackgroundPsql swallowing errors on windows