public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Bertrand Drouvot <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: [email protected]
Cc: Zsolt Parragi <[email protected]>
Subject: Re: Flush some statistics within running transactions
Date: Tue, 24 Feb 2026 10:56:16 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>
References: <aZQTCJJm61J/[email protected]>
<CAA5RZ0vDh+vbE5SY-+azQBxEhXrywaXGrK_Qn8DKEBwNsrDH_Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA5RZ0u2Vi4-PvHsFBS6aHpoi-uNQjDaLxnAwXxRuUf6ZDMs3Q@mail.gmail.com>
<[email protected]>
<CAA5RZ0t1DsB5x_reGAv0AcKdKuF5FTowUx54SLnWkD3w5vH4Lg@mail.gmail.com>
<[email protected]>
<CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>
On Mon, Feb 23, 2026 at 05:47:22PM -0600, Sami Imseih wrote:
>> I think the logic for fixed stats and variable stats should be the same. If
>> not we could observe discrepancies: for example a long running select could
>> genereate reads/hits IO visible in pg_stat_io but tuples_returned, tuples_fetched,
>> blocks_fetched or blocks_hit would not be updated until the session goes idle.
>
> After having more time to think about this, I believe it can be much simpler.
> As soon as we enter an idle-in-transaction (aborted) state, we can simply
> schedule an anytime update. This ensures that a flush is scheduled whenever
> the fixed stats trigger one, which will likely be the most common reason
> (e.g., I/O stats, WAL stats, etc.). To cover the cases where fixed stats
> do not schedule a flush, we can also schedule one as soon as a transaction
> goes idle.
>
> In my mind, this makes this whole flushing scheduling behavior easy to reason
> about, and if we introduce future anytime stats anywhere, we are not required
> to schedule a flush for each individual field. The flush callback will of course
> still need to decide what to flush anytime or at the transaction boundary.
>
> What do you think?
I cannot picture yet fully how a patch among these lines would be
shaped, but having a strategic flush of the stats when we are in an
idle-in-transaction state sounds like an interesting option here.
I think that this leans towards two first pieces of infrastructure for
this patch set:
- The new stats kind option.
- A new pgstats API that is able to classify the flushes depending on
property assigned for each stats kind, and make these happen on a
caller-basis.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
view thread (22+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Flush some statistics within running transactions
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox