Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1kkStO-00052u-Am
	for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Dec 2020 14:14:02 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1kkStN-0002Q0-9X
	for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Dec 2020 14:14:01 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <sk@zsrv.org>)
	id 1kkStM-0002Pt-TS
	for pgsql-hackers@lists.postgresql.org; Wed, 02 Dec 2020 14:14:01 +0000
Received: from forward501p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b7:120])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <sk@zsrv.org>)
	id 1kkStK-0002pw-Mx
	for pgsql-hackers@postgresql.org; Wed, 02 Dec 2020 14:14:00 +0000
Received: from mxback5g.mail.yandex.net (mxback5g.mail.yandex.net
 [IPv6:2a02:6b8:c03:7aa:0:640:f183:746])
	by forward501p.mail.yandex.net (Yandex) with ESMTP id 086B835001D6;
	Wed,  2 Dec 2020 17:13:57 +0300 (MSK)
Received: from localhost (localhost [::1])
	by mxback5g.mail.yandex.net (mxback/Yandex) with ESMTP id
 TXPdydRPpj-DuR8XbEY;
	Wed, 02 Dec 2020 17:13:56 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zsrv.org; s=mail;
 t=1606918436;
	bh=a3bjEP1rYMAjsYGomcdApBxY46KUlRZuxxfGGUvCff0=;
	h=References:Date:Message-Id:Subject:In-Reply-To:To:From;
	b=mkHWn2MsFdV7Rda+ndECBqUYmkmXvxpSTLcdyQKIhSPuUe8h6Pch3tKd0LhLAMRPM
	 8GG004oKSHSXVaKpcXzSpL8EszhKX58xqCpT6Bs5ywnohhN2w/D+vcC/Z49jyeExWW
	 k5KFZk+N+5V2ad32U2JEwf4d68OeGz5UBiXZyKYQ=
Authentication-Results: mxback5g.mail.yandex.net; dkim=pass header.i=@zsrv.org
Received: by myt3-e312fc6a36c4.qloud-c.yandex.net with HTTP;
	Wed, 02 Dec 2020 17:13:56 +0300
From: Sergei Kornilov <sk@zsrv.org>
To: legrand legrand <legrand_legrand@hotmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
In-Reply-To: <1606916496022-0.post@n3.nabble.com>
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>
Subject: Re: pg_stat_statements oddity with track = all
MIME-Version: 1.0
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Wed, 02 Dec 2020 17:13:56 +0300
Message-Id: <861161606917332@mail.yandex.ru>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

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.

Also, currently a top statement will account buffers usage for underlying statements?

regards, Sergei