Re: perform_spin_delay() vs wait events
От | Robert Haas |
---|---|
Тема | Re: perform_spin_delay() vs wait events |
Дата | |
Msg-id | CA+TgmoZE-4xDXL=hdtDWFd1o9hSzawxQVCT6QtCTSYoLO8CQaQ@mail.gmail.com обсуждение исходный текст |
Ответ на | perform_spin_delay() vs wait events (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: perform_spin_delay() vs wait events
|
Список | pgsql-hackers |
On Sun, Nov 20, 2022 at 3:43 PM Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: