Re: REPACK and naming

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REPACK and naming
Date: 2025-09-17 14:22:22
Message-ID: 1505300.1758118942@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2025-Sep-17, David G. Johnston wrote:
>> Concretely, maybe we should remove vacuum full from the vacuum command
>> page, and just call it out as compatibility spelling of repack on its
>> page. Maybe do the same for cluster (I haven’t dived into the new feature
>> enough to confidently describe all this yet though).

> I think we should list VACUUM FULL as deprecated, document that feature
> in the REPACK documentation page, and leave VACUUM FULL in working state
> so as not to break existing scripts. Same for CLUSTER.

I'm not at all in love with documenting VACUUM FULL and CLUSTER as
being fundamentally the same thing. I think that is an implementation
happenstance that could go away as easily as it appeared. Even if you
think we'll never again rewrite it for heap, what of other table AMs?
The underlying reality could be totally different for them.

By and large, I don't think I like this renaming proposal.
Maybe eventually it would reduce confusion, but there will be
a long interval where it adds more.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2025-09-17 14:49:05 Re: How can end users know the cause of LR slot sync delays?
Previous Message Peter Geoghegan 2025-09-17 14:15:10 Re: Remove PointerIsValid()