On Mon, Aug 10, 2020 at 4:09 PM Magnus Hagander <magnus@hagander.net> wrote: > Would it even solve the problem for them? pg_stat_statements collects aggregate stats and not a view of what's happening right now -- so it'd be mixing two different types of values. And it would get worse if the same thing is executed multiple times concurrently.
True. You could find that you have a queryId that had already been evicted from the table.
I think it's better to look for a more direct solution to this problem.
I am thinking about an extension (but it can be in core too) that does copy query string and execution plan to shared memory to separate buffers per session (before query start). It should eliminate a problem with performance with locks
There can be two functions
show_query(pid int, "top" bool default true) .. it shows query without truncating
show_plan(pid int, "top" bool default true, format text default "text")
When the argument "top" is false, then you can see the current query.
