From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Laetitia Avrot <laetitia.avrot@gmail.com>,
        Peter Eisentraut <peter@eisentraut.org>,
        Japin Li <japinli@hotmail.com>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        John Naylor <john.naylor@enterprisedb.com>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: Statistics updates is delayed when using `commit and chain`
In-reply-to: <20220801164004.kybukw4j3svgcv54@awork3.anarazel.de>
References: 
 <CAKFQuwYnpkDkeKHh7xwMAUqarcYiw9QDg8+Umz7THmEbCH7SzA@mail.gmail.com>
 <3455196.1626234760@sss.pgh.pa.us>
 <CAKFQuwaTDMYW0v2cv+CxLfnyJ_OAh=Pc0YKvD8f3xc3DtB_LHQ@mail.gmail.com>
 <CAKFQuwZSi6vWEUtZKQhqzHj8FeWtgon=HJ-BGLfpRwjErpwKGw@mail.gmail.com>
 <MEYP282MB16691F2B962B05BB1AC5C151B6139@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
 <CAB_COdjhzA+9URWOekr3s=J-+kMsUQDcjae2rF00Z5X-jDKzuA@mail.gmail.com>
 <MEYP282MB16691A6E80DF769F04BF9EB0B6E99@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
 <CAB_COdiHgHsUb7qxftTe9S-fagXr3Xv+Grw5rcdjwvu2pYy1uA@mail.gmail.com>
 <20220801161256.ogcacmw6txiecvfb@awork3.anarazel.de>
 <1839632.1659371158@sss.pgh.pa.us>
 <20220801164004.kybukw4j3svgcv54@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 01 Aug 2022 09:40:04 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1845219.1659372203.1@sss.pgh.pa.us>
Date: Mon, 01 Aug 2022 12:43:23 -0400
Message-ID: <1845220.1659372203@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1845220.1659372203%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-08-01 12:25:58 -0400, Tom Lane wrote:
>> What I suggested a few days ago is that it should be in CommitTransaction.

> I wonder how we'd best deal with the idle timer if we go for that. That only
> makes sense in some contexts (normal backends), but not others (everything
> else).

Yeah.  I think we'd need to get rid of the "bool force" argument
of pgstat_report_stat, and instead have it manage things internally
based on understanding whether the current process uses a reporting
timeout timer or not (if not, always send the report right away).
That seems like it'd be more robust than the current mechanism anyway,
as we're currently relying on every call site to get that right.

			regards, tom lane