Re: Extended Prefetching using Asynchronous IO - proposal and patch

Поиск
Список
Период
Сортировка
От John Lumby
Тема Re: Extended Prefetching using Asynchronous IO - proposal and patch
Дата
Msg-id BAY175-W35C03DA8661D4FE3E1E57AA3190@phx.gbl
обсуждение исходный текст
Ответ на 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
My cut'n'pasting failed me at one point corrected below.


> discussion about what is the difference between a synchronous read
> versus an asynchronous read as far as non-originator waiting on it is concerned.
>
> I thought a bit more about this.   There are currently two differences,
> one of which can easily be changed and one not so easy.
>
> 1)     The current code,  even with sigevent,  still makes the non-originator waiter
>          call aio_error on the originator's aiocb to get the completion code.
>          For sigevent variation,  easily changed to have the originator always call aio_error
>          (from its CHECK_INTERRUPTS or from FIleCompleteaio)
>          and store that in the BAiocb.
>          My idea of why not to do that  was that,  by having the non-originator check the aiocb,
>         this would allow the waiter to proceed sooner.   But for a different reason it actually
>          doesn't.   (The non-originator must still wait for the LWlock release)
>
>   2)   Buffer pinning and  returning the BufferAiocb to the free list
>         With synchronous IO,    each backend that calls a ReadBuffer must pin the buffer
>         early in the process.
>         With asynchronous IO,    initially only the originator gets the pin
>         (and that is during PrefetchBuffer,  not Readbuffer)
>          When the aio completes and some backend checks that completion,
>         then the backend has various responsibilities:
>
>                .   pin the buffer if it did not already have one (from prefetch)
>                .  if it was the last such backend to make that check
>                   (amongst the cohort waiting on it)
>                    then XXXXXXpin the buffer if it did not already have one (from prefetch)XXXX

then return the BufferAiocb to the free list




В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Lumby
Дата:
Сообщение: Re: Extended Prefetching using Asynchronous IO - proposal and patch
Следующее
От: Amit Langote
Дата:
Сообщение: Re: makeAndExpr(), etc. confined to gram.y?