Re: Avoid full GIN index scan when possible

Marc Cousin <cousinmarc(at)gmail(dot)com> writes:
> By the way, while preparing this, I noticed that it seems that during this kind of index scan, the interrupt signal is masked
> for a very long time. Control-C takes a very long while to cancel the query. But it's an entirely different problem :)

Yeah, that seems like an independent problem/patch, but it's not obvious
where to fix --- can you provide a self-contained test case?

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;

regards, tom lane