Re: Request for feature: VACUUM FULL updates pg_stat_all_tables.last_vacuum

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Cc: 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-09 14:49:48
Message-ID: CAKFQuwbhDpOwB25TAEhcE9gTf8UK_aei98pae5Q0yBWLaO=KWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Thu, May 9, 2024 at 7:21 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:

> On Thu, May 9, 2024 at 10:07 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Thu, May 9, 2024 at 6:58 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
>> wrote:
>>
>>>
>>> I'm not wedded to the name RECREATE TABLE, but am wedded to the fact
>>> that VACUUM FULL is a horrible name for what it does.
>>>
>>>
>> I think there is general agreement here but your cure is arguably worse
>> than the disease.
>>
>
> Why? RECREATE TABLE says exactly what it does: recreates the table, and
> *doesn't* pretend to do something it doesn't do (vacuum the table).
>
>
That's distracting from the question at hand, which is whether and how to
go about changing this, not whether the alternative naming is better than
the existing one. It isn't so much better that the pain of change seems
worth it. Mostly because it isn't like the universe simply gets
reprogrammed to map the old onto the new, and having the old and new
co-exist produces a burden.

David J.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Ron Johnson 2024-05-09 14:53:50 Re: Request for feature: VACUUM FULL updates pg_stat_all_tables.last_vacuum
Previous Message Ron Johnson 2024-05-09 14:21:18 Re: Request for feature: VACUUM FULL updates pg_stat_all_tables.last_vacuum