Re: Extended Prefetching using Asynchronous IO - proposal and patch
От | Greg Stark |
---|---|
Тема | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
Дата | |
Msg-id | CAM-w4HMGMkNL+WpDDEp+9sd+idZ1rxEJLaALLCFs0URNJGcyjA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extended Prefetching using Asynchronous IO - proposal and patch (John Lumby <johnlumby@hotmail.com>) |
Ответы |
Re: Extended Prefetching using Asynchronous IO - proposal and patch
|
Список | pgsql-hackers |
On Mon, Jun 23, 2014 at 2:43 PM, John Lumby <johnlumby@hotmail.com> wrote: > It is when some *other* backend gets there first with the ReadBuffer that > things are a bit trickier. The current version of the patch did polling for that case > but that drew criticism, and so an imminent new version of the patch > uses the sigevent mechanism. And there are other ways still. I'm a bit puzzled by this though. Postgres *already* has code for this case. When you call ReadBuffer you set the bits on the buffer indicating I/O is in progress. If another backend does ReadBuffer for the same block they'll get the same buffer and then wait until the first backend's I/O completes. ReadBuffer goes through some hoops to handle this (and all the corner cases such as the other backend's I/O completing and the buffer being reused for another block before the first backend reawakens). It would be a shame to reinvent the wheel. The problem with using the Buffers I/O in progress bit is that the I/O might complete while the other backend is busy doing stuff. As long as you can handle the I/O completion promptly -- either in callback or thread or signal handler then that wouldn't matter. But I'm not clear that any of those will work reliably. -- greg
В списке pgsql-hackers по дате отправления: