Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

Hello.

At Fri, 19 Jan 2018 01:16:56 +0300, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote in <CAPpHfdvJeYrnAsXhKRfO_NMDUaWQyK+wyhcv4zOdRzTdfNCkkw(at)mail(dot)gmail(dot)com>
> On Thu, Jan 18, 2018 at 8:48 AM, Kyotaro HORIGUCHI <
> horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:

> > Index only scan is not usable in the case since the first index
> > column cannot be rechecked but check_index_only makes wrong
> > decision by the second occurance of "w'. There may be a chance
> > that recheck is not required but we cannot predict that until
> > actually acquire a tuple during execution.
> >
>
> I didn't get this point. Same column is indexed twice using two
> different opclasses. The first opclass doesn't support index-only scan,
> while the second opclass does support it. So, if the first opclass needs
> recheck then it can be rechecked using the value got from the second
> opclass. Thus, I think we can potentially support index-only scan
> in this case.
> Another thing is that it's probably hard to do in our current
> optimizer/executor/am
> infrastructure. And assuming that use-case is quite narrow, and it looks

To be exact, you're right. My description was abridged by
omitting exactly what you mentioned above. The complexity needed
to allow that doesn't seem worth adding.

> OK to just disable such feature as bug fix.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center