Feedback-ID: ia2694551:Fastmail
Date: Fri, 10 May 2024 13:21:08 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Nikolay Samokhvalov <samokhvalov@gmail.com>
Cc: Ron Johnson <ronljohnsonjr@gmail.com>,
	Laurenz Albe <laurenz.albe@cybertec.at>,
 Pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: Request for feature: VACUUM FULL updates
 pg_stat_all_tables.last_vacuum
Message-ID: <202405101121.lnko2euk3ohc@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CANNMO+K2ikym0DpV8CeDcoM9wvoThNVPxh7_xVC8_V=10o-kcw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202405101121.lnko2euk3ohc%40alvherre.pgsql>
Precedence: bulk

On 2024-May-09, Nikolay Samokhvalov wrote:

> With RECREATE TABLE, one day, we would be probably have RECREATE TABLE
> CONCURRENTLY implemented, making pg_repack less needed.

If we really wanted to rename VACUUM FULL, I would go for a name that
betrays its CLUSTER implementation -- maybe CLUSTER UNSORTED or so --
and document it together with regular CLUSTER.  We don't really need a
new top-level command for it IMO.

As for pg_repack, I'd much rather get VACUUM SQUEEZE using pg_squeeze as
an implementation starting point (without the scheduling stuff though.)

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/