| 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 |
| 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 |