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

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Sami Imseih <samimseih(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-08-24 13:04:19
Message-ID: aoxBU0MGGYHxX2sJ@bdtpg
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Aug 24, 2026 at 07:26:38AM -0500, Sami Imseih wrote:
> > /* 24 | 8 */ PgStat_Counter tuples_hot_updated;
> > /* 32 | 8 */ PgStat_Counter tuples_newpage_updated;
> > /* 40 | 1 */ _Bool truncdropped;
> > /* XXX 7-byte hole */
> > /* 48 | 8 */ PgStat_Counter delta_live_tuples;
> > /* 56 | 8 */ PgStat_Counter delta_dead_tuples;
> > /* 64 | 8 */ PgStat_Counter changed_tuples;
>
> right, These counters should be confined to PgStat_Counter fields,
> and we can similar to what was done in 3cd3a039da7 to ensure
> that the struct has no padding, using StaticAssertDecl().
>
> truncdropped should be moved under PgStat_RelationStatus
> directly, since it's not a counter anyhow.
>
> I still think this is a much better way to organize the data and retain the
> capability to do memcmp() rather than field-by-field comparisons.
>
> WDYT?

Yeah, that would address my concern and keep memcmp(), so +1.

Regards,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Miłosz Bieniek 2026-08-24 12:53:50 Re: Apply worker can pick an invalid index for REPLICA IDENTITY FULL lookups