Re: Latches vs lwlock contention - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Latches vs lwlock contention
Date
Msg-id CA+hUKG+UfnpJwxUJO-XoAJ-JabXAhmkTwwjG8HLfi7XiQz_bxA@mail.gmail.com
Whole thread Raw
In response to Latches vs lwlock contention  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Latches vs lwlock contention
List pgsql-hackers
On Fri, Oct 28, 2022 at 4:56 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> See attached sketch patches.  I guess the main thing that may not be
> good enough is the use of a fixed sized latch buffer.  Memory
> allocation in don't-throw-here environments like the guts of lock code
> might be an issue, which is why it just gives up and flushes when
> full; maybe it should try to allocate and fall back to flushing only
> if that fails.

Here's an attempt at that.  There aren't actually any cases of uses of
this stuff in critical sections here, so perhaps I shouldn't bother
with that part.  The part I'd most like some feedback on is the
heavyweight lock bits.  I'll add this to the commitfest.

Attachment

pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Improve tab completion for ALTER TABLE on identity columns