From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, John Lumby <johnlumby(at)hotmail(dot)com>, pgsql hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
Date: | 2014-05-29 21:49:07 |
Message-ID: | CAGTBQpYEUVj28u4mkNJms59SBtiiisjjSL6akHdVeChvnt1T+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, May 29, 2014 at 6:43 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Thu, May 29, 2014 at 6:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
>>> Didn't fix that, but the attached patch does fix regression tests when
>>> scanning over index types other than btree (was invoking elog when the
>>> index am didn't have ampeeknexttuple)
>>
>> "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.
Though, your comment does illustrate the need to document that on
ampeeknexttuple, for future users.
From | Date | Subject | |
---|---|---|---|
Next Message | John Lumby | 2014-05-29 21:53:51 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
Previous Message | Claudio Freire | 2014-05-29 21:43:02 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
From | Date | Subject | |
---|---|---|---|
Next Message | John Lumby | 2014-05-29 21:53:51 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
Previous Message | Claudio Freire | 2014-05-29 21:43:02 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |