Date: Thu, 3 Dec 2020 16:52:08 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Sergei Kornilov <sk@zsrv.org>
Cc: legrand legrand <legrand_legrand@hotmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: pg_stat_statements oddity with track = all
Message-ID: <20201203085208.GB8050@nol>
References: <20201202040516.GA43757@nol>
 <CANNMO+KrVxMTrzSJLkrkENQX7utVYo1SEyaW54N+Y-Zjew=wbQ@mail.gmail.com>
 <20201202063241.GA51769@nol>
 <dc48d183-65a2-8f12-3581-ab8f3faeab8b@oss.nttdata.com>
 <20201202082402.GB51769@nol>
 <1606916496022-0.post@n3.nabble.com>
 <861161606917332@mail.yandex.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <861161606917332@mail.yandex.ru>
Precedence: bulk

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.