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