Re: Statistics updates is delayed when using `commit and chain`

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 23:03:19
Message-ID: 20220801230319.2nexdq43vrghdzbr@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2022-08-01 13:22:35 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2022-08-01 12:43:23 -0400, Tom Lane wrote:
> >> 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).
>
> > It's not as simple as looking at the backend type, I think. We'd not want to
> > enable a timer in the commit-and-chain context, even in a normal backend -
> > there's no chance we'll go idle.
>
> No, but that's not the point. During CommitTransaction we should check
> to see if it's more than X amount of time since our last stats report,
> and if so send a new one. No timer interaction involved there. When
> we go idle, if not inside a transaction and a report needs to be sent,
> then compute the wait time till it should be sent and set a timer for
> that.

I don't quite see how that'd help us to get rid of the force argument -
somehow pgstat_report_stat() needs to know that it it should "block" reporting
stats. Which we e.g. want when the idle timer has elapsed.

> > I wonder if it was the wrong call to use timers for IdleSessionTimeout,
> > IdleInTransactionSessionTimeout and pgstats. We always use nonblocking socket
> > IO these days, so perhaps we should instead just compute a relevant timeout
> > for the WaitEventSetWait() call?
>
> Meh. I think that that would end up with duplicative logic and
> duplicative gettimeofday calls, unless your idea is to get rid of
> the timeout.c facilities altogether.

I suspect it'd reduce the number of gettimeofday calls, but yes, the
duplication wouldn't be nice.

I guess there's a chance we could get rid of most of the timeout.c stuff, but
it'd need changes in a fair number of places... Don't think it's worth doing
atm.

Greetings,

Andres Freund

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Smith 2022-08-02 01:54:39 Re: Excessive number of replication slots for 12->14 logical replication
Previous Message Tom Lane 2022-08-01 22:21:18 Re: BUG #17565: Extended query protocol incorrectly sets TBLOCK_STARTED even though multiple queries can be executed