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 1lPFrE-0006G2-6A for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Mar 2021 02:36:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lPFrB-0003WM-Ts for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Mar 2021 02:36:21 +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 1lPFrB-0003WF-L4 for pgsql-hackers@lists.postgresql.org; Thu, 25 Mar 2021 02:36:21 +0000 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lPFr5-0007oJ-5A for pgsql-hackers@lists.postgresql.org; Thu, 25 Mar 2021 02:36:21 +0000 Received: by mail-pg1-x531.google.com with SMTP id i22so327860pgl.4 for ; Wed, 24 Mar 2021 19:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=o4ahpLd4m81CNGpGficz4Yk/Lu0SPWI1JS9ZsPB7D4U=; b=GQzNqiVzTemNB+2tzgeMaKe3Xw9MeIGdHw7odDtiM9FAYA0HfGGRiDLAO5Up6lYr/o agbKhg344z2V5jy/ZWs3eV6LYniVIBI0YfOCSba5MBlJ/TVONjaaNUi6RYnqNQV6gk3M 7+tlJSsdPFqT36BRQr6x9jBqTaBHmpqsOJ/ZY+Mc/5FXy4wgDFIZH4/RoUJ5/5S5VVRU DbSjYCZ8vRtDcDOQP9CmjLLgZQjVjm+oEHRqKwvZE6TCNXMCL9xmeSzaXjxm8jJEg93d CVD8EpWoClOuLkQd7o82N8sYrGqBu0Q0GiMeOwEco0cEfF7gk2p+hLttnI0cFvpkXv4A FgNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=o4ahpLd4m81CNGpGficz4Yk/Lu0SPWI1JS9ZsPB7D4U=; b=GcE8lbTwJkn9GUgILkIc7tKzQiNhnTl9yIGWZPsqz9y/RJ9LRlWA9QvSY1VoRZoJVE H1dRaPihVYSmPnkbcXL895Q4Ly1OhqT4ibUeGZNvvc9AbSaTGu4qqFVKPZnaVFgQWtJy h7xFG894XZiwIAWVmdNQarD182RjVr8SOKoaHpFkfBzdshCbNsuwv9X1f9kj4BverCQ7 Uvhr0JgUxpF9gq8wVS+kBTNOvfihAmfN2KCnAfZT3Zvzd4Jm7pWBobMYdu4mCx3goSrD ejHliAiyBaeRsA5312Dw3LuFIMvjtxEDoCJTd+utSGPA5QzH6NA+ZhMpeLAGC/Bzk+ec KCpA== X-Gm-Message-State: AOAM531p5Vboo/JY6hPUYP1r41s2S1merxxUReMX9iPxX7iieK9GifAK 8Qbt8gcQWCXGzeSmUxyuq80= X-Google-Smtp-Source: ABdhPJwyeIadNQMI4cbvii16rGc5YFNN/vd48OfRKLQ7eZIaTUcCBvLN2Y9om0D2FaiepM+GtbGZ3w== X-Received: by 2002:a17:902:bf07:b029:e7:137c:2e25 with SMTP id bi7-20020a170902bf07b02900e7137c2e25mr1837866plb.67.1616639772232; Wed, 24 Mar 2021 19:36:12 -0700 (PDT) Received: from nol (2001-b011-0008-5a94-87c0-1014-431f-3df2.dynamic-ip6.hinet.net. [2001:b011:8:5a94:87c0:1014:431f:3df2]) by smtp.gmail.com with ESMTPSA id x2sm3532705pgb.89.2021.03.24.19.36.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Mar 2021 19:36:11 -0700 (PDT) Date: Thu, 25 Mar 2021 10:36:38 +0800 From: Julien Rouhaud To: Alvaro Herrera 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: <20210325023638.rb5534543nkradyf@nol> References: <20210324152049.cjv2op3jsgauutwv@nol> <20210324160200.GA21214@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210324160200.GA21214@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote: > 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. The current queryid is already available in the Estate, as the underlying PlannedStmt contains it. The problem is that we want to display the top level queryid, not the current query one, and the top level queryid is held in pgstat.