Re: Avoid full GIN index scan when possible - Mailing list pgsql-hackers

On Wed, Jul 31, 2019 at 5:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Meanwhile, I looked at the v3 patch, and it seems like it might not be
> too far from committable.  I think we should *not* let this get bogged
> down in questions of whether EXPLAIN can report which index quals were
> used or ignored.  That's a problem that's existed for decades in the
> btree code, with more or less zero user complaints.
>
> I do think v3 needs more attention to comments, for instance this
> hunk is clearly falsifying the adjacent comment:
>
> @ -141,7 +141,8 @@ ginFillScanKey(GinScanOpaque so, OffsetNumber attnum,
>         uint32          i;
>
>         /* Non-default search modes add one "hidden" entry to each key */
> -       if (searchMode != GIN_SEARCH_MODE_DEFAULT)
> +       if (searchMode != GIN_SEARCH_MODE_DEFAULT &&
> +               (searchMode != GIN_SEARCH_MODE_ALL || nQueryValues))
>                 nQueryValues++;
>         key->nentries = nQueryValues;
>         key->nuserentries = nUserQueryValues;
>
> Also, I agree with Julien that this
>
> +                       so->forcedRecheck = key->triConsistentFn(key) != GIN_TRUE;
>
> probably needs to be
>
> +                       so->forcedRecheck |= key->triConsistentFn(key) != GIN_TRUE;

Ping, Julien?  Based on the above, it looks like if we had a
last-minute patch addressing the above this could go directly to Ready
for Committer?  I will hold off moving this one to CF2 until my
morning.

-- 
Thomas Munro
https://enterprisedb.com