Re: BUG #16303: A condtion whether an index-only scan is possible includes a wrong

Hello,

Thank you for your explanation.
I understand what you say.

Thank you,

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: BUG #16303: A condtion whether an index-only scan is possible includes a wrong
Date: Mon, 16 Mar 2020 11:20:43 -0400

> Horimoto Yasuhiro <horimoto(at)clear-code(dot)com> writes:
>> So I think that choosing index-only scan for this case (false is returned by gistcanreturn() case)
>> isn't expected behavior.
>
> You're mistaken. An index-only scan is not only useful but potentially
> quite desirable for queries such as count(*); in the best case it ends
> up just counting the index entries without ever visiting the heap at all.
>
> It does look a bit weird that we might select an IOS for an index type
> that can't ever return any column values, but so far as I can see it
> should work fine. The index isn't being asked to do anything that it
> doesn't have to do anyway, ie, return the correct set of heap TIDs.
> Testing locally with a GIST index gives the right answers, too.
>
>> We found the problem I reported with PGroonga:
>> https://github.com/pgroonga/pgroonga/issues/101
>
>> This problem causes an error because PGroonga can't return
>> IndexScanDesc::xs_itup but IndexScanDesc::xs_want_itup is true.
>> Because PostgreSQL requests index-only scan even when PGroonga
>> returns false by amcanreturn().
>
> You should be returning an empty, zero-column tuple (either itup
> or htup format) in that situation. The limit of "I don't have
> any columns I can return" is to form a tuple with no columns,
> not to fail to form a tuple.
>
> regards, tom lane
>
>