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@sss.pgh.pa.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@clear-code.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
> 
>