Re: Avoid full GIN index scan when possible

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Avoid full GIN index scan when possible
Дата
Msg-id CAOBaU_Y7K_VjCQUfZzYf3iFXscnO-rGk1o+eH6xBs-fth5N0-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoid full GIN index scan when possible  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Avoid full GIN index scan when possible  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Avoid full GIN index scan when possible  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Aug 1, 2019 at 8:43 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Wed, Jul 31, 2019 at 5:28 AM Tom Lane <tgl@sss.pgh.pa.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.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergei Kornilov
Дата:
Сообщение: Re: allow online change primary_conninfo
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: SQL:2011 PERIODS vs Postgres Ranges?