From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: perform_spin_delay() vs wait events |
Date: | 2022-11-20 22:26:11 |
Message-ID: | CA+TgmoZE-4xDXL=hdtDWFd1o9hSzawxQVCT6QtCTSYoLO8CQaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 20, 2022 at 3:43 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> The lwlock wait queue scalability issue [1] was quite hard to find because of
> the exponential backoff and because we adjust spins_per_delay over time within
> a backend.
>
> I think the least we could do to make this easier would be to signal spin
> delays as wait events. We surely don't want to do so for non-contended spins
> because of the overhead, but once we get to the point of calling pg_usleep()
> that's not an issue.
>
> I don't think it's worth trying to hand down more detailed information about
> the specific spinlock we're waiting on, at least for now. We'd have to invent
> a whole lot of new wait events because most spinlocks don't have ones yet.
>
> I couldn't quite decide what wait_event_type to best group this under? In the
> attached patch I put it under timeouts, which doesn't seem awful.
I think it would be best to make it its own category, like we do with
buffer pins.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-11-20 22:32:19 | Re: More efficient build farm animal wakeup? |
Previous Message | Roberto C. Sánchez | 2022-11-20 22:00:45 | Re: Question concerning backport of CVE-2022-2625 |