From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Wait events for delayed checkpoints |
Date: | 2023-10-12 17:32:29 |
Message-ID: | CA+TgmoYvG4u_6V5v=ZsC5ZEzuH8jsrC5KDfppDXedF9vLmLyhA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 11, 2023 at 9:13 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> You can't tell if your checkpointer is spending a lot of time waiting
> around for flags in delayChkptFlags to clear. Trivial patch to add
> that. I've managed to see it a few times when checkpointing
> repeatedly with a heavy pgbench workload.
>
> I had to stop and think for a moment about whether these events belong
> under "WaitEventIPC", "waiting for notification from another process"
> or under "WaitEventTimeout", "waiting for a timeout to expire". I
> mean, both? It's using sleep-and-poll instead of (say) a CV due to
> the economics, we want to make the other side as cheap as possible, so
> we don't care about making the checkpointer take some micro-naps in
> this case. I feel like the key point here is that it's waiting for
> another process to do stuff and unblock it.
IPC seems right to me. Yeah, a timeout is being used, but as you say,
that's an implementation detail.
+1 for the idea, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-10-12 17:34:57 | Re: On login trigger: take three |
Previous Message | Robert Haas | 2023-10-12 17:28:57 | Re: Eager page freeze criteria clarification |