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


Reply via email to