MIME-Version: 1.0
References: <aWTVEycKj7Qh/SXH@ip-10-97-1-34.eu-west-3.compute.internal>
In-Reply-To: <aWTVEycKj7Qh/SXH@ip-10-97-1-34.eu-west-3.compute.internal>
From: Sami Imseih <samimseih@gmail.com>
Date: Wed, 14 Jan 2026 21:54:17 -0600
Message-ID: <CAA5RZ0vgN8nf7yPrk_uNt-ABFtRnRuz7-9CM=qSzUSwj=EEUKw@mail.gmail.com>
Subject: Re: Flush some statistics within running transactions
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA5RZ0vgN8nf7yPrk_uNt-ABFtRnRuz7-9CM%3DqSzUSwj%3DEEUKw%40mail.gmail.com>
Precedence: bulk

Hi,

Thanks for these patches!

I took a quick look at the patches and I have some general comments.

> Long running transactions can accumulate significant statistics (WAL, IO,=
 ...)
> that remain unflushed until the transaction ends. This delays visibility =
of
> resource usage in monitoring views like pg_stat_io and pg_stat_wal.

+1. I do think this is a good idea. Long-running transactions cause accumul=
ated
stats to appear as spikes in monitoring tools rather than as gradual activi=
ty.
This would help level out, though not eliminate, those artificial spikes.

> The 1 second flush interval is currently hardcoded but we could imagine i=
ncrease
> it or make it configurable.

Someone may want to turn this off as well. I think a GUC will be needed.

> RELATION stats are making use of FLUSH_MIXED:

> stats: numscans, tuples_returned, tuples_fetched, blocks_fetched,
> blocks_hit

I=E2=80=99m concerned that fields being temporarily out of sync might impac=
t monitoring
calculations, if the formula is dealing with fields that have
different flush strategies.
That said, minor discrepancies are usually tolerable for monitoring
data analysis.

For the numscans, should we not also update the scan timestamp?

--
Sami Imseih
Amazon Web Services (AWS)