Re: Avoid full GIN index scan when possible

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marc Cousin <cousinmarc(at)gmail(dot)com>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Avoid full GIN index scan when possible
Date: 2019-07-30 17:27:48
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-30 17:36:36 Re: TopoSort() fix
Previous Message Tom Lane 2019-07-30 16:56:48 Re: make installcheck-world in a clean environment