Re: Avoid full GIN index scan when possible

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marc Cousin <cousinmarc(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, 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-08-01 10:37:44
Message-ID: CAOBaU_a_b7CkfkYovZ7GDHpnicqZqtOE3autdsmfL1NqVwCbPQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 1, 2019 at 12:13 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Thu, Aug 1, 2019 at 8:43 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> >
> > On Wed, Jul 31, 2019 at 5:28 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > 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;
> >
> > Ping, Julien? Based on the above, it looks like if we had a
> > last-minute patch addressing the above this could go directly to Ready
> > for Committer? I will hold off moving this one to CF2 until my
> > morning.
>
> Attached v4 that should address all comments.

And of course, thanks a lot! Sorry for the message sent quite
precipitately, I'm also dealing with plumbing issues this morning :(

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-08-01 10:49:39 Re: Referential Integrity Checks with Statement-level Triggers
Previous Message Etsuro Fujita 2019-08-01 10:36:05 Re: [HACKERS] advanced partition matching algorithm for partition-wise join