Andres Freund <and...@anarazel.de> writes:
> 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.
Maybe not queue a new timeout if the old one is still active?
BTW, it looks like that patch also falsified this comment
(postgres.c:4478):
* At most one of these timeouts will be active, so there's no
need to
* worry about combining the timeout.c calls into one.
Maybe fixing that end of things would be a simpler way of buying back
the delta.
> Or we could add a timeout.c API that specifies the timeout?
Don't think that will help: it'd be morally equivalent to
enable_timeout_at(), which also has to do GetCurrentTimestamp().
regards, tom lane
