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 ) id 1lP5xV-0000Tb-QG for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Mar 2021 16:02:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lP5xU-0007wk-Nf for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Mar 2021 16:02:12 +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 ) id 1lP5xU-0007wd-HB for pgsql-hackers@lists.postgresql.org; Wed, 24 Mar 2021 16:02:12 +0000 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lP5xS-000200-CW for pgsql-hackers@lists.postgresql.org; Wed, 24 Mar 2021 16:02:12 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 1D535102C; Wed, 24 Mar 2021 12:02:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 24 Mar 2021 12:02:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=GI6Lzhyz5Fh6uR7+/cCQcqaG789BxV54UEJOcA9fSHM=; b=QKX4z41x TCA+mo253NBwy5Ro7rGZ6u/OBm1NYn4gH4TXc+/fWJlDTqIF8FtBVxKL++kcpw7T OopALO9FmtIMiTXBTpW45Z1IeurNE4E1NoZ+6QHed4wy+jWWoe5Jc3m9l8Sg8ajq IqueOAjhshptnMEf32iP1w3443oeseMlyPtGj8Y4pGLS+EMVOwH46FcvI04ur/fz kV/DfuWWFE9cSHd0ZIRYpFBx18nL+xmq9/mW3pYl2tgpXOpiag++s/BbxE8xFfky zf5d0+BfT+Nh4p3FLWrOeS96D1aIXC9beWlSg1W6rNwESFPeIAyfHNeXyJ6ismHa WS27nUpzAxfCGA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudegkedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesthekredttderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepueffhfejieeuueffgedvudekgeeltdeviedvieeufeei ieevgfetheeufeethedvnecukfhppeduledtrdelhedrudelrdelheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 445801080064; Wed, 24 Mar 2021 12:02:03 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id AEC492A0FB1; Wed, 24 Mar 2021 13:02:00 -0300 (-03) Date: Wed, 24 Mar 2021 13:02:00 -0300 From: Alvaro Herrera To: Julien Rouhaud Cc: Bruce Momjian , Hannu Krosing , Robert Haas , Pavel Stehule , Tom Lane , Michael Paquier , torikoshia , Atsushi Torikoshi , Tatsuro Yamada , Tomas Vondra , Evgeny Efimkin , PostgreSQL Hackers Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? Message-ID: <20210324160200.GA21214@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210324152049.cjv2op3jsgauutwv@nol> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Mar-24, Julien Rouhaud wrote: > From e08c9d5fc86ba722844d97000798de868890aba3 Mon Sep 17 00:00:00 2001 > From: Bruce Momjian > Date: Mon, 22 Mar 2021 17:43:23 -0400 > Subject: [PATCH v20 2/3] Expose queryid in pg_stat_activity and > src/backend/executor/execMain.c | 9 ++ > src/backend/executor/execParallel.c | 14 ++- > src/backend/executor/nodeGather.c | 3 +- > src/backend/executor/nodeGatherMerge.c | 4 +- Hmm... I find it odd that there's executor code that acquires the current query ID from pgstat, after having been put there by planner or ExecutorStart itself. Seems like a modularity violation. I wonder if it would make more sense to have the value maybe in struct EState (or perhaps there's a better place -- but I don't think they have a way to reach the QueryDesc anyhow), put there by ExecutorStart, so that places such as execParallel, nodeGather etc don't have to fetch it from pgstat but from EState. -- Álvaro Herrera Valdivia, Chile "We're here to devour each other alive" (Hobbes)