Re: Extended Prefetching using Asynchronous IO - proposal and patch - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Extended Prefetching using Asynchronous IO - proposal and patch
Date
Msg-id CAGTBQpYTp_QuWLQpxxNjoWC5Au9MKnxNHCcoOcNtVToPJtjzLg@mail.gmail.com
Whole thread Raw
In response to Re: Extended Prefetching using Asynchronous IO - proposal and patch  (John Lumby <johnlumby@hotmail.com>)
List pgsql-hackers
On Thu, May 29, 2014 at 7:11 PM, John Lumby <johnlumby@hotmail.com> wrote:
>> Nonetheless, getting the next tid out of the index may involve stepping
>> to the next index page, at which point you've lost your interlock
>
> I think we are ok as peeknexttuple (yes  bad name,  sorry,  can change it
> ...
> never advances to another page  :
>
>  *    btpeeknexttuple() -- peek at the next tuple different from any
> blocknum in pfch_list
>  *                           without reading a new index page
>  *                       and without causing any side-effects such as
> altering values in control blocks
>  *               if found,     store blocknum in next element of pfch_list


Yeah, I was getting to that conclusion myself too.

We could call it amprefetchnextheap, since it does just prefetch, and
is good for nothing *but* prefetch.



pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Extended Prefetching using Asynchronous IO - proposal and patch
Next
From: John Lumby
Date:
Subject: Re: Extended Prefetching using Asynchronous IO - proposal and patch