On 18/01/2024 5:57 pm, Tomas Vondra wrote:
> On 1/16/24 21:10, Konstantin Knizhnik wrote:
>> ...
>>
>>> 4. I think that performing prefetch at executor level is really great
>>>> idea and so prefetch can be used by all indexes, including custom
>>>> indexes. But prefetch will be efficient only if index can provide fast
>>>> access to next TID (located at the same page). I am not sure that it is
>>>> true for all builtin indexes (GIN, GIST, BRIN,...) and especially for
>>>> custom AM. I wonder if we should extend AM API to make index make a
>>>> decision weather to perform prefetch of TIDs or not.
>>> I'm not against having a flag to enable/disable prefetching, but the
>>> question is whether doing prefetching for such indexes can be harmful.
>>> I'm not sure about that.
>> I tend to agree with you - it is hard to imagine index implementation
>> which doesn't win from prefetching heap pages.
>> May be only the filtering case you have mentioned. But it seems to me
>> that current B-Tree index scan (not IOS) implementation in Postgres
>> doesn't try to use index tuple to check extra condition - it will fetch
>> heap tuple in any case.
>>
> That's true, but that's why I started working on this:
>
> https://commitfest.postgresql.org/46/4352/
>
> I need to think about how to combine that with the prefetching. The good
> thing is that both changes require fetching TIDs, not slots. I think the
> condition can be simply added to the prefetch callback.
>
>
> regards
>
Looks like I was not true, even if it is not index-only scan but index
condition involves only index attributes, then heap is not accessed
until we find tuple satisfying search condition.
Inclusive index case described above
(https://commitfest.postgresql.org/46/4352/) is interesting but IMHO
exotic case. If keys are actually used in search, then why not to create
normal compound index instead?