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

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