Re: Flush some statistics within running transactions

Hi Jakub!

On Wed, Feb 18, 2026 at 12:37:01PM +0100, Jakub Wartak wrote:
> On Wed, Feb 18, 2026 at 6:41 AM Bertrand Drouvot
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> >
>
> Thanks for working on this. I've took a quick look on this patchset:

Thanks!

> however that function (get_timeout_active()) is not static inlined so I'm
> wondering wouldn't there some major performance impact?

The get_timeout_active() function is very simple but you are right to be
concerned by the extra function call in hot paths.

So, with a simple pgbench test as:

pgbench -i -s 1
pgbench -n -c1 -j1 -f <(echo "SELECT count(*) FROM pgbench_accounts;") -T 60

1/ with the patch

tps average over 5 runs is about 123.8 and a perf report reports:

0.44% postgres postgres [.] get_timeout_active
0.43% <blabla>;ExecAgg;fetch_input_tuple;IndexOnlyNext;get_timeout_active

To compare with other solutions that will not make use of a get_timeout_active()
function call, let's also check the IndexOnlyNext profile (see above as to why):

12.05% postgres postgres [.] IndexOnlyNext

2/ without the patch

tps average over 5 runs is about 124.9 and a perf report reports:

11.59% postgres postgres [.] IndexOnlyNext

3/ with the patch and get_timeout_active() inlined:

tps average over 5 runs is about 124 and a perf report reports:

10.89% postgres postgres [.] IndexOnlyNext

4/ with the patch and using a boolean instead of get_timeout_active()

tps average over 5 runs is about 129 and a perf report reports:

11.88% postgres postgres [.] IndexOnlyNext

I'm not 100% sure what to conclude here.
What I can see is that get_timeout_active() was about 0.45%, that's not a lot
but that is simple enough to remove that I think that we just should.

> - but the main question is: why do we need that often to recheck and re-enable
> timers so often from such hot places?

We need to ensure that anytime stats are flushed each time we update an anytime
stats. Kind of the same idea as with the existing "pgstat_report_fixed".

> v8-0001: this patch modifies ProcessInterrupts() which checks for
> AnytimeStatsUpdateTimeoutPending and it may happen that it takes LWLocks
> (pgstat_report_anytime_stat()->pgstat_flush_pending_entries()->e.g.
> pgstat_*_flush_cb()-> pgstat_lock_entry() -> LWLock)
>
> (It's more a question than finding): isn't it too risky to take that
> LWLock from potentially random spots as the CHECK_FOR_INTERRUPTS() is
> literally everywhere (~318 places). Wouldn't it be safer to flush
> from a couple of desired places?

That's a good question. pgstat_report_stat() is already called in ProcessInterrupts()
and pgstat_report_anytime_stat() does not do more than it, so I'm tempted to say
that we are fine here.

PFA, a new version that:

- Implements the boolean (i.e "pgstat_pending_anytime") usage instead of the
get_timeout_active() call.
- Fix a race in assign_stats_flush_interval() reported by Sami off thread.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com