Re: Index-only scan returns incorrect results when using acomposite GIST index with a gist_trgm_ops column. - Mailing list pgsql-bugs

From Kyotaro HORIGUCHI
Subject Re: Index-only scan returns incorrect results when using acomposite GIST index with a gist_trgm_ops column.
Date
Msg-id 20180119.100036.129395697.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Index-only scan returns incorrect results when using a compositeGIST index with a gist_trgm_ops column.  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-bugs
Hello.

At Fri, 19 Jan 2018 01:16:56 +0300, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote in
<CAPpHfdvJeYrnAsXhKRfO_NMDUaWQyK+wyhcv4zOdRzTdfNCkkw@mail.gmail.com>
> On Thu, Jan 18, 2018 at 8:48 AM, Kyotaro HORIGUCHI <
> horiguchi.kyotaro@lab.ntt.co.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



pgsql-bugs by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Index-only scan returns incorrect results when using a compositeGIST index with a gist_trgm_ops column.
Next
From: Will Storey
Date:
Subject: Re: BUG #15007: LIMIT not respected in sub-queries