Re: Should io_method=worker remain the default?
От | Thomas Munro |
---|---|
Тема | Re: Should io_method=worker remain the default? |
Дата | |
Msg-id | CA+hUKG+c7DQAEu8AFb+Zt7yF4+VugWDymgOF_0qde8ysZxfJRw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should io_method=worker remain the default? (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
On Thu, Sep 4, 2025 at 10:47 AM Jeff Davis <pgsql@j-davis.com> wrote: > Andres suggested that the case I brought up at the top of the thread is > due to lock contention, so a lock free queue also sounds like a > potential improvement. If the code is working and can be applied to > REL_18_STABLE, then I can try it. Not easily, unfortunately, that was a while back and I'd need to find all the bits and rebase. There is a preliminary step in CF5913[1]: it splits AioWorkerSubmissionQueueLock's duties into AioWorkerControlLock for pool management and AioWorkerSubmissionQueueLock for the queue itself. I had a couple of different attempts at generic lock free queues, one from a paper and one loosely based on FreeBSD's buf_ring.h, but I'm not at all sure it's actually any good and I found it quite tricky to integrate with the idle bitmap scheme which so far seems to be valuable... Hmm, it might be good to try some simpler things first: splitting AioWorkerSubmissionQueueLock into a producer lock (backends enqueuing) and a consumer lock (workers dequeuing) must surely help a lot. I'll try to come up with some simple patches to evaluate... [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGJLe-0E-wZ-is78CEHhjbC%3DihMVCQLoN1dmD-j05s9qRg%40mail.gmail.com#c3eb6c873b7218d5c3d5164244f7245d
В списке pgsql-hackers по дате отправления: