Re: Flush SLRU counters in checkpointer process

From: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Flush SLRU counters in checkpointer process
Date: 2023-01-12 08:45:31
Message-ID: CAO6_XqrK3CZXKD4mMbmB=pYzXcyZxdWqpT45__fyTzLnriyrMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 11, 2023 at 5:33 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2023-01-11 10:29:06 +0100, Anthonin Bonnefoy wrote:
> > Currently, the Checkpointer process only reports SLRU statistics at
> server
> > shutdown, leading to delayed statistics for SLRU flushes. This patch
> adds a
> > flush of SLRU stats to the end of checkpoints.
>
> Hm. I wonder if we should do this even earlier, by the
> pgstat_report_checkpointer() calls in CheckpointWriteDelay().
>
> I'm inclined to move the pgstat_report_wal() and pgstat_report_slru() calls
> into pgstat_report_checkpointer() to avoid needing to care about all the
> individual places.
>
That would make sense. I've created a new patch with everything moved in
pgstat_report_checkpointer().
I did split the checkpointer flush in a pgstat_flush_checkpointer()
function as it seemed more readable. Thought?

> > @@ -505,6 +505,7 @@ CheckpointerMain(void)
> > /* Report pending statistics to the cumulative stats
> system */
> > pgstat_report_checkpointer();
> > pgstat_report_wal(true);
> > + pgstat_report_slru(true);
>
> Why do we need a force parameter if all callers use it?

Good point. I've written the same signature as pgstat_report_wal but
there's no need for the nowait parameter.

Attachment Content-Type Size
flush-slru-counters-v2.patch application/octet-stream 5.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2023-01-12 08:54:40 Re: Fix condition in shm_toc and remove unused function shm_toc_freespace.
Previous Message Julien Rouhaud 2023-01-12 08:37:38 Re: Lazy allocation of pages required for verifying FPI consistency