Re: pgstat: Flush some statistics within running transactions, take 2

From: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>
Subject: Re: pgstat: Flush some statistics within running transactions, take 2
Date: 2026-09-02 16:16:08
Message-ID: CAN12+YJ_kS+bhLHXJJ9kYUS+_UZp5emNKuCZnE7YBVx1m1LJSA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The scan only performs one backend local bool write per pending entry, so
> this
> is probably negligible compared to the actual flush work. A pass generation
> could avoid the extra scan, but I'm not sure that would be worth the
> additional
> complexity.
>
> What do you think?

The scan only does one backend-local write per pending entry, so it is
negligible compared to the flush work itself. I benchmarked a
workload touching 1, 2, 4, 8, ... up to 512 empty relations per
transaction across 1, 2, 4, ... up to 256 clients, and did not see any
differences beyond noise of +/-1% tps differences.

Even so, I think the pass-generation approach is the better idea here. It's
slightly more code, but it avoids the extra full-list reset pass. I will
feel
better with the generational counter.

--
Sami Imseih
Amazon Web Services (AWS)

Attachment Content-Type Size
v11-0001-pgstat-Split-table-stat-counters-into-transactio.patch application/octet-stream 25.8 KB
v11-0002-pgstat-Allow-pg_stat_force_next_flush-to-work-in.patch application/octet-stream 98.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2026-09-02 16:30:20 Follow-up review items for update_deleted
Previous Message Matthias van de Meent 2026-09-02 15:59:33 Re: glist: _Generic wrapper for selective dlist/dclist usage