What about using wait events and a trigger on pg_stat_activity ?
pg_stat_activity should not to show fresh data. Using pg_stat_activity can be too expensive for fast queries
just :
* create a functions to get current query signature (queryid) for a pid
(not the top_level_query given for pl/pgsql blocks or triggers but the active one)
* add some kind of active events to track planning (in an extension with a planning hook)
and populate some continuous views as proposed by pipelinedb (a very flexible solution).
Yes, I know a trigger is not possible, and overhead of continuous views has not been verified, then some high frequency sampling on pg_stat_activity could help (I can provide examples for f_get_current_queryid(pid), active event for planning hook, continuous views)
An other solution: a customized version of pgsentinel (for high frequency sampling):
I don't believe to sampling method - I talk about less than 10ms queries, I would to see a 2-3ms planning time, 2-5ms waitings - and it means sampling aboy 2ms, what is expensive