| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Laetitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Japin Li <japinli(at)hotmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Statistics updates is delayed when using `commit and chain` |
| Date: | 2022-08-01 16:43:23 |
| Message-ID: | 1845220.1659372203@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-08-01 17:10:51 | Re: Statistics updates is delayed when using `commit and chain` |
| Previous Message | Andres Freund | 2022-08-01 16:40:04 | Re: Statistics updates is delayed when using `commit and chain` |