On Mon, Jul 17, 2023 at 10:25 PM Andres Freund 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
On Wed, Jul 19, 2023 at 06:49:57PM +0530, Amit Kapila wrote:
> On Mon, Jul 17, 2023 at 10:26 PM Andres Freund wrote:
>> 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 gives
On Mon, Jul 17, 2023 at 10:26 PM Andres Freund wrote:
>
> Previously it was e.g. not really possible to distinguish that something like
> this:
>
> ┌┬─┬┬───┐
> │ backend_type │ wait_event_type │ wait_event │ count │
>
Hi,
In a number of workloads one can see two wait events prominently:
LWLock:WALWrite and LWLock:WALInsert. Unfortunately for both that is not very
informative:
LWLock:WALWrite can be reported because there is genuine contention on the
LWLock, or, more commonly, because several backends are
