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

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
ismasked 
> 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