Re: Report distinct wait events when waiting for WAL "operation"

On Mon, Jul 17, 2023 at 10:25 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> Therefore I'm proposing that LWLockAcquireOrWait() and LWLockWaitForVar() not
> use the "generic" LWLockReportWaitStart(), but use caller provided wait
> events. The attached patch adds two new wait events for the existing callers.

+1 for having separate wait events for WAL insert lock acquire and
wait for WAL insertions to finish. However, I don't think we need to
pass wait events to LWLockAcquireOrWait and LWLockWaitForVar, we can
just use wait events directly in the functions. Because these two
functions are used for acquiring WAL insert lock and waiting for WAL
insertions to finish, they aren't multipurpose functions.

> I waffled a bit about which wait event section to add these to. Ended up with
> "IPC", but would be happy to change that.
>
> WAIT_EVENT_WAL_WAIT_INSERT WALWaitInsert "Waiting for WAL record to be copied into buffers."
> WAIT_EVENT_WAL_WAIT_WRITE WALWaitWrite "Waiting for WAL buffers to be written or flushed to disk."

IPC seems okay to me. If not, how about the PG_WAIT_LWLOCK event
class? Or, have WAIT_EVENT_WAL_WAIT_WRITE under PG_WAIT_IO and the
other under PG_WAIT_IPC?

> ┌────────────────┬─────────────────┬───────────────┬───────┐
> │ backend_type │ wait_event_type │ wait_event │ count │
> ├────────────────┼─────────────────┼───────────────┼───────┤
> │ client backend │ IPC │ WALWaitInsert │ 22 │
> │ client backend │ LWLock │ WALInsert │ 13 │
> │ client backend │ LWLock │ WALBufMapping │ 5 │
> │ walwriter │ (null) │ (null) │ 1 │
> │ client backend │ Client │ ClientRead │ 1 │
> │ client backend │ (null) │ (null) │ 1 │
> └────────────────┴─────────────────┴───────────────┴───────┘
>
> even though they are very different
>
> FWIW, the former is bottlenecked by the number of WAL insertion locks, the
> second is bottlenecked by copying WAL into buffers due to needing to flush
> them.

This separation looks clean and gives much more info.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com