At Thu, 16 Jun 2022 23:24:56 -0700, Andres Freund <and...@anarazel.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