Hi Sami, On Sun, Mar 1, 2026 at 7:44 AM Sami Imseih <[email protected]> wrote: > I do agree that having such additional information, with proper > documentation, is a good idea. However, I do wonder if we should hold > off on adding any of this info in 19 because of the point you make > below, which could completely change the information we need to > expose. Adding this information in 19 and then removing it for 20 may > not be worthwhile.
Yeah, I suspect you're right - I'll mark this as returned with feedback for now. > > I've had a patch to improve this prepared for a previous cycle, but > > wasn't sure it was still needed because of the discussion re: keeping > > query texts in shared memory. But since it looks like that won't > > change for 19 (though I'm hoping to contribute more to improving that > > in the PG 20 cycle), see attached for consideration. > > 19 has 4ba012a8ed, which allows us to serialize and deserialize query > texts stored in, for example, DSA, with a dsa_pointer tracked by the > entry of a custom stats kind. I was also planning on continuing this > work for 20, and getting 4ba012a8ed was an important prerequisite for > this. Yup, makes sense - I think 4ba012a8ed is a foundational piece to make progress on this in 20. I've also been wondering if we should prototype a new pg_stat_statements module separately (e.g. in a GitHub repo, "pg_stat_statements_next" or something), just to allow quicker iteration and allow easier testing of a pure in-memory approach, before bringing it to the discussion table for -hackers later in the PG20 cycle. Thanks, Lukas -- Lukas Fittl
