On 12/30/24 22:40, Jim Nasby wrote:
> On Dec 25, 2024, at 11:25 AM, Tomas Vondra <tomas@vondra.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).
>
True, although I'd point out the 128MB was meant to be a maximum for a
GUC, not the default. The default in the patch was 1MB, and with a lots
of instances on the same machine, those can't be very active so this
would probably be enough.
Anyway, with the simple file-based solution this would go away.
> 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.
regards
--
Tomas Vondra
