On 12/30/24 22:40, Jim Nasby wrote: > On Dec 25, 2024, at 11:25 AM, Tomas Vondra <to...@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
