Re: Request for featu VACUUM FULL updates pg_stat_all_tables.last_vacuum

Ha! I’ve followed this all day.

 

1. VACUUM FULL should not be renamed, no matter what it actually does.  Do you realize how many scripts worldwide would need to be changed? Lol.
2. It’s OpenSource.  Grab the source, change whatever names you want, and now your PG is how you want it!

 

From: Nikolay Samokhvalov <samokhvalov@gmail.com>
Sent: Thursday, May 9, 2024 2:13 PM
To: Ron Johnson <ronljohnsonjr@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: [EXTERNAL] Re: Request for feature: VACUUM FULL updates pg_stat_all_tables.last_vacuum

 

On Thu, May 9, 2024 at 13:39 Ron Johnson <ronljohnsonjr@gmail.com> wrote:

On Thu, May 9, 2024 at 4:11 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:

On Thu, 2024-05-09 at 09:58 -0400, Ron Johnson wrote:
> Because vacuum is vacuum.

The problem is that the two commands do something different, so it
would be misleading.  Renaming VACUUM (FULL) is a good idea in principle,
but I think that is more than 10 years too late.  The compatibility
break would be too painful.

 

Make VACUUM (FULL) a synonym for RECREATE TABLE, then say in the docs that VACUUM (FULL) is deprecated.

 

Then drop it in PG 27...

 

Perhaps you could write a patch to add a column "last_rewritten"
to "pg_stat_all_tables"...

 

I'm a worse C programmer than I am a DBA. 

 

It's never late.

 

I like the idea of RECREATE TABLE  and deprecating VACUUM FULL a lot. It always seemed to me a non-user-friendly naming choice like pg_xlog or psql's \q, both of which are solved already.

 

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