Re: PoC: history of recent vacuum/checkpoint runs (using new hooks)

From: Jim Nasby <jnasby(at)upgrade(dot)com>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PoC: history of recent vacuum/checkpoint runs (using new hooks)
Date: 2024-12-31 20:54:15
Message-ID: 542D5C59-32C7-4AD3-BB22-5B841E79AA89@upgrade.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec 31, 2024, at 9:20 AM, Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>
>> Speaking of retention, it would be nice if this feature allowed users to
>> DELETE from the view that presented the data. That would allow for any
>> kind of custom config that someone could dream up.
>
> I really don't intend / want to do that. That significantly increases
> the complexity, turning an append-only file into something that's
> essentially almost a regular table. Yes, even with the append-only file
> there's need to be a way to deal with dropped objects, but supporting
> arbitrary deletes seems much more demanding.
>
> There should be a way to reset the stats, of course. But only a fairly
> coarse one.

My thought was that you’d just accumulate the pkey of everything being deleted until end of transaction and then use that to rewrite the table. On the surface that doesn’t seem too terrible, especially depending on how dropped objects as well as aging out old data is handled.

Either way I just wanted to put the idea out there as something I think would be useful, especially since it might influence parts of the simple design. I certainly agree it’s not a mandatory feature.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2024-12-31 21:35:02 Re: add vacuum starttime columns
Previous Message Bruce Momjian 2024-12-31 20:52:07 Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)