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

From Tom Lane
Subject Re: Extended Prefetching using Asynchronous IO - proposal and patch
Date
Msg-id 18398.1401400617@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extended Prefetching using Asynchronous IO - proposal and patch  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: Extended Prefetching using Asynchronous IO - proposal and patch
Re: Extended Prefetching using Asynchronous IO - proposal and patch
List pgsql-hackers
Claudio Freire <klaussfreire@gmail.com> writes:
> On Thu, May 29, 2014 at 6:43 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> On Thu, May 29, 2014 at 6:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> "ampeeknexttuple"?  That's a bit scary.  It would certainly be unsafe
>>> for non-MVCC snapshots (read about vacuum vs indexscan interlocks in
>>> nbtree/README).

>> It's not really the tuple, just the tid

> And, furthermore, it's used only to do prefetching, so even if the tid
> was invalid when the tuple needs to be accessed, it wouldn't matter,
> because the indexam wouldn't use the result of ampeeknexttuple to do
> anything at that time.

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
guaranteeing that the *previous* tid will still mean something by the time
you arrive at its heap page.  I presume that the ampeeknexttuple call is
issued before trying to visit the heap (otherwise you're not actually
getting much I/O overlap), so I think there's a real risk here.

Having said that, it's probably OK as long as this mode is only invoked
for user queries (with MVCC snapshots) and not for system indexscans.
        regards, tom lane



pgsql-hackers by date:

Previous
From: John Lumby
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