Re: pg_stat_statements oddity with track = all
От | Julien Rouhaud |
---|---|
Тема | Re: pg_stat_statements oddity with track = all |
Дата | |
Msg-id | 20201203085208.GB8050@nol обсуждение исходный текст |
Ответ на | Re: pg_stat_statements oddity with track = all (Sergei Kornilov <sk@zsrv.org>) |
Список | pgsql-hackers |
On Wed, Dec 02, 2020 at 05:13:56PM +0300, Sergei Kornilov wrote: > Hello > > > - add a parent_statement_id column that would be NULL for top level queries > > Will generate too much entries... Every FK for each different delete/insert, for example. > But very useful for databases with a lot of stored procedures to find where this query is called. May be new mode track= tree? Use NULL to indicate a top-level query (same as with track=tree) and some constant for any nested queries whentrack = all. Maybe pg_stat_statements isn't the best tool for that use case. For the record the profiler in plpgsql_check can now track queryid for each statements inside a function, so you match pg_stat_statements entries. That's clearly not perfect as dynamic queries could generate different queryid, but that's a start. > Also, currently a top statement will account buffers usage for underlying statements? I think so.
В списке pgsql-hackers по дате отправления: