Re: Should io_method=worker remain the default?
От | Andres Freund |
---|---|
Тема | Re: Should io_method=worker remain the default? |
Дата | |
Msg-id | g47verzfgnilmrestdb6o6echny4543fxmohkzqzcgasxvl7yl@752bn66qespk обсуждение исходный текст |
Ответ на | Re: Should io_method=worker remain the default? (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Should io_method=worker remain the default?
Re: Should io_method=worker remain the default? |
Список | pgsql-hackers |
Hi, On 2025-09-08 12:08:10 -0700, Jeff Davis wrote: > On Mon, 2025-09-08 at 14:39 +1200, Thomas Munro wrote: > > Some raw thoughts on this topic, and how we got here: This type of > > extreme workload, namely not doing any physical I/O, just copying the > > same data from the kernel page cache to the buffer pool over and over > > again, > > Isn't that one of the major selling points of AIO? It does "real > readahead" from kernel buffers into PG buffers ahead of the time, so > that the backend doesn't have to do the memcpy and checksum > calculation. I don't think accelerating copying from the pagecache into postgres shared buffers really is a goal of AIO. It can be a nice side-effect, but not more. I'd say the absolute number one goal of AIO is to reduce the amount of synchronously waiting for IO in the "foreground". An important, but secondary, goal is to offload work from the CPU, via DMA - but that fundamentally only can work with DIO. > The only problem right now is that it doesn't (yet) work great when the > concurrency is higher because: > > (a) we don't adapt well to saturated workers; and > (b) there's lock contention on the queue if there are more workers Afaict you've not explained in what even remotely plausible scenario you'd have where > 30GB/s of reads from the page cache. I continue to maintain that the workload presented does not exist in the real world. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: