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 по дате отправления:

Предыдущее
От: Sergei Kornilov
Дата:
Сообщение: Re: pg_stat_statements oddity with track = all
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: pg_stat_statements oddity with track = all