Hi,
On Wed, Sep 03, 2025 at 02:47:51PM +0900, Michael Paquier wrote:
> On Tue, Sep 02, 2025 at 12:42:54PM -0400, Andres Freund wrote:
> > I think that's the wrong direction to go. Diffing stats is far from cheap
> > and
> > gets more expensive the more detail you add to stats.
>
> Even if we onl
On Tue, Sep 02, 2025 at 12:42:54PM -0400, Andres Freund wrote:
> On 2025-09-02 08:19:22 +0900, Michael Paquier wrote:
>> On Mon, Sep 01, 2025 at 02:07:27PM +, Bertrand Drouvot wrote:
>>> Instead, it now copies the IO pending stats to the backend IO pending stats
>>> when
>>> the pending IO sta
On Mon, Sep 01, 2025 at 02:07:27PM +, Bertrand Drouvot wrote:
> Instead, it now copies the IO pending stats to the backend IO pending stats
> when
> the pending IO stats are flushed. This behaves the same way as for some
> relation
> and database stats (see pgstat_relation_flush_cb()).
>
> I
Hi,
On 2025-09-02 08:19:22 +0900, Michael Paquier wrote:
> On Mon, Sep 01, 2025 at 02:07:27PM +, Bertrand Drouvot wrote:
> > Instead, it now copies the IO pending stats to the backend IO pending stats
> > when
> > the pending IO stats are flushed. This behaves the same way as for some
> > re
Hi,
On Tue, Sep 02, 2025 at 07:41:59AM +, Bertrand Drouvot wrote:
> On Tue, Sep 02, 2025 at 08:19:22AM +0900, Michael Paquier wrote:
> > Removing both the function calls and the extra counter incrementations
> > means to do the same thing as the WAL stats, where we have one
> > structure in ch
Hi,
On Tue, Sep 02, 2025 at 08:19:22AM +0900, Michael Paquier wrote:
> On Mon, Sep 01, 2025 at 02:07:27PM +, Bertrand Drouvot wrote:
> > Instead, it now copies the IO pending stats to the backend IO pending stats
> > when
> > the pending IO stats are flushed. This behaves the same way as for
