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-30 21:40:34
Message-ID: 4D223CC0-1028-4172-803A-C89A71E942C0@upgrade.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec 25, 2024, at 11:25 AM, Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> But maybe it'd be possible to just write the entries to a file. We don't
> need random access to past entries (unlike e.g. pg_stat_statements), and
> people won't query that very often either.

Assuming this doesn’t add significant complexity I think file-based would be the best way to go. It allows for more meaningful retention policies (ie, “1 month”) that don’t equate to storage size. More importantly, it removes the need to try and scale these limits based on hardware. While 128MB isn’t a huge amount on modern hardware, it’s also not nothing (especially if it can’t be swapped). This is especially true in an environment with a lot of small database instances (ie, at work our default instance has 8GB of memory, and it’d be nice to reduce that even more).

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Roberto C. Sánchez 2024-12-30 21:50:12 Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)
Previous Message Peter Smith 2024-12-30 21:17:51 Re: Documentation update of wal_retrieve_retry_interval to mention table sync worker