| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
| Cc: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Request for feature: VACUUM FULL updates pg_stat_all_tables.last_vacuum |
| Date: | 2024-05-10 11:21:08 |
| Message-ID: | 202405101121.lnko2euk3ohc@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Achilleas Mantzios - cloud | 2024-05-10 11:30:46 | PostgreSQL on netapp AFF C250A storage ? |
| Previous Message | Wells Oliver | 2024-05-09 23:14:06 | Confirming pg_repack being successful |