| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Michael Banck <mbanck(at)gmx(dot)net>, Antonin Houska <ah(at)cybertec(dot)at>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: why there is not VACUUM FULL CONCURRENTLY? |
| Date: | 2025-02-03 20:27:07 |
| Message-ID: | Z6Emm1Sj8Xz1hoFO@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 30, 2025 at 04:29:35PM +0100, Alvaro Herrera wrote:
> 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.
+1
One small thing I thought of after the meeting was that this effectively
forces users to always specify an index if they want to REPACK WITH INDEX.
Today, CLUSTER will use the same index as before if one is not specified.
IMHO requiring users to specify the index is entirely reasonable, but I
figured I'd at least note the behavior change.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-02-03 20:29:03 | Re: improve DEBUG1 logging of parallel workers for CREATE INDEX? |
| Previous Message | Sami Imseih | 2025-02-03 20:18:21 | Prevent COPY FREEZE on Foreign tables |