Re: Avoid full GIN index scan when possible

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Avoid full GIN index scan when possible
Дата
Msg-id 19189.1564687723@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Avoid full GIN index scan when possible  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: Avoid full GIN index scan when possible  (Nikita Glukhov <n.gluhov@postgrespro.ru>)
Список pgsql-hackers
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> On Thu, Aug 1, 2019 at 9:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> While I've not attempted to fix that here, I wonder whether we shouldn't
>> fix it by just forcing forcedRecheck to true in any case where we discard
>> an ALL qualifier.

> +1 for setting forcedRecheck in any case we discard ALL qualifier.
> ISTM, real life number of cases we can skip recheck here is
> negligible.  And it doesn't justify complexity.

Yeah, that was pretty much what I was thinking --- by the time we got
it fully right considering nulls and multicolumn indexes, the cases
where not rechecking could actually do something useful would be
pretty narrow.  And a bitmap heap scan is always going to have to
visit the heap, IIRC, so how much could skipping the recheck really
save?

>> BTW, it's not particularly the fault of this patch, but: what does it
>> even mean to specify GIN_SEARCH_MODE_ALL with a nonzero number of keys?

> It might mean we would like to see all the results, which don't
> contain given key.

Ah, right, I forgot that the consistent-fn might look at the match
results.

            regards, tom lane



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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Avoid full GIN index scan when possible
Следующее
От: Corey Huinker
Дата:
Сообщение: Re: Referential Integrity Checks with Statement-level Triggers