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 1oHB1i-0001UM-9g for pgsql-bugs@arkaria.postgresql.org; Thu, 28 Jul 2022 21:26:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oHB1h-0000NK-1U for pgsql-bugs@arkaria.postgresql.org; Thu, 28 Jul 2022 21:26:37 +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 1oHB1g-0000NB-PK for pgsql-bugs@lists.postgresql.org; Thu, 28 Jul 2022 21:26:36 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHB1e-0001iB-Gp for pgsql-bugs@lists.postgresql.org; Thu, 28 Jul 2022 21:26:36 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 26SLQRvT3554912; Thu, 28 Jul 2022 17:26:27 -0400 From: Tom Lane To: Laetitia Avrot cc: Japin Li , "David G. Johnston" , John Naylor , PostgreSQL mailing lists Subject: Re: Statistics updates is delayed when using `commit and chain` In-reply-to: References: <2950681.1626103840@sss.pgh.pa.us> <3453636.1626232720@sss.pgh.pa.us> <3455196.1626234760@sss.pgh.pa.us> Comments: In-reply-to Laetitia Avrot message dated "Sat, 14 May 2022 17:11:33 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3554910.1659043587.1@sss.pgh.pa.us> Date: Thu, 28 Jul 2022 17:26:27 -0400 Message-ID: <3554911.1659043587@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Laetitia Avrot writes: > [ v3-0001-update-table-stats-after-commit-and-chain.patch ] I took a quick look at this. If we're going to move the responsibility for pushing out stats to transaction commit, then I think what we want to do is put the call somewhere near the end of CommitTransaction. Maybe right after AtCommit_Notify, because that has the same spirit of sending out info about our having committed to other backends. (The pgstat_report_xact_timestamp call would need to be moved up to before that, I think, but that sure looks like it was inserted with the aid of a dartboard anyway. It certainly doesn't square with the immediately preceding comment about "purely internal" cleanup.) AbortTransaction and probably PrepareTransaction the same. Having done that, rather than adding more pgstat_report_stat calls we could get rid of most of them. I see a bunch of random calls right after various CommitTransactionCommand calls, which we'd not need anymore. We probably still want the one in PostgresMain, but it needs some rethinking, because we only want that one to do something when the timer fires saying that we've slept too long without sending stats. As for the NOTIFY business, I'm not impressed with putting duplicate boilerplate into half a dozen different places. I think the discussion in ref/notify.sgml covers this already, or if not, that's the one place to fix it. The place I actually thought could use more attention is the wire protocol spec in protocol.sgml. In any case, I'd rather see that as a separate patch, because it's unrelated. regards, tom lane