Re: Avoid full GIN index scan when possible

Marc Cousin <cousinmarc@gmail.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