Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

At Thu, 16 Jun 2022 23:24:56 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in
> The remaining difference looks like it's largely caused by the
> enable_timeout_after(IDLE_STATS_UPDATE_TIMEOUT, ...) introduced as part of the
> pgstats patch. It's only really visible when I pin a single connection pgbench
> to the same CPU core as the server (which gives a ~16% boost here).
>
> It's not the timeout itself - that we amortize nicely (via 09cf1d522). It's
> that enable_timeout_after() does a GetCurrentTimestamp().
>
> Not sure yet what the best way to fix that is.
>
> We could just leave the timer active and add some gating condition indicating
> idleness to the IdleStatsUpdateTimeoutPending body in ProcessInterrupts()?
>
> Or we could add a timeout.c API that specifies the timeout?

I sometimes wanted this, But I don't see a simple way to sort multiple
relative timeouts in absolute time order. Maybe we can skip
GetCurrentTimestamp only when inserting the first timeout, but I don't
think it benefits this case.

> pgstat_report_stat() uses GetCurrentTransactionStopTimestamp(), it seems like
> it'd make sense to use the same for arming the timeout?

This seems like the feasible best fix for this specific issue.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center