Re: Flush some statistics within running transactions

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Subject: Re: Flush some statistics within running transactions
Date: 2026-02-24 16:32:43
Message-ID: CAA5RZ0uJvCH1U47+m8eCW_NHv+F8W484MBDLw_kc6AfLY74xTw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > 2) The need for all the stats to call pgstat_schedule_anytime_update()
> > in strategical places. This is less of a burden compared to 1), but
> > this leads to more complications in these code paths with the coding
> > requirements, especially for custom stats kinds.
>
> I think that's solved with Sami's proposal for variable stats kind (to flush or
> schedule when the session is idle).

Just a clarification. It is "to schedule a flush when the transaction
becomes idle"
PGSTAT_IDLE_INTERVAL already deals when the session is idle.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Induja Sreekanthan 2026-02-24 16:33:03 BUG: ReadStream look-ahead exhausts local buffers when effective_io_concurrency>=64
Previous Message Nathan Bossart 2026-02-24 16:27:25 Re: Proposal: ANALYZE (MODIFIED_STATS) using autoanalyze thresholds