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