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.
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) |