From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Sergei Kornilov <sk(at)zsrv(dot)org> |
Cc: | legrand legrand <legrand_legrand(at)hotmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_statements oddity with track = all |
Date: | 2020-12-03 08:52:08 |
Message-ID: | 20201203085208.GB8050@nol |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 when track = 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-12-03 08:53:59 | Re: pg_stat_statements oddity with track = all |
Previous Message | Sergei Kornilov | 2020-12-03 08:40:22 | Re: pg_stat_statements oddity with track = all |