From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
cc: Julien Rouhaud <rjuju123@gmail.com>,
 Thomas Munro <thomas.munro@gmail.com>,
        Marc Cousin <cousinmarc@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Avoid full GIN index scan when possible
In-reply-to: 
 <CAPpHfdvfK+Zk=MjjC1M_66+ALD+vdR6BG3quoFAZzjL6hNv-NQ@mail.gmail.com>
References: 
 <CAOBaU_YGP5-BEt5Cc0=zMve92vocPzD+XiZgiZs1kjY0cj=XBg@mail.gmail.com>
 <CAOBaU_ZCg4955_HGcQZdn44wtTQRpiHkLgkVsxqQ5cfymDL-XQ@mail.gmail.com>
 <20190628161051.szk2kxmue6yjdmra@development>
 <CAOBaU_ZCJBm3mGvJpMN4VX4Q2oQvgPEwMA1jJyrb7-P0HJbnQA@mail.gmail.com>
 <4547.1561748599@sss.pgh.pa.us> <20190628195401.frwhcga76rrytbc4@development>
 <7773.1561752983@sss.pgh.pa.us>
 <CAOBaU_bDF-7E5x0WVPmmtoc+0z7S3hmcXnnV+1ggy8CMGyZxgg@mail.gmail.com>
 <eca8612b-e289-e2fc-c5df-84be46f75ec1@gmail.com>
 <27217.1564507668@sss.pgh.pa.us>
 <CA+hUKGLeu3d31K-zKmyMpgqSYc54zJ0zz2ihQCQtAPZBJNAijg@mail.gmail.com>
 <CAOBaU_Y7K_VjCQUfZzYf3iFXscnO-rGk1o+eH6xBs-fth5N0-w@mail.gmail.com>
 <12611.1564670226@sss.pgh.pa.us>
 <CAOBaU_b3u1xpoESb2JD6dQ4V7fhwmbfOFW5PiadZHJX6bNdnfw@mail.gmail.com>
 <17590.1564685940@sss.pgh.pa.us>
 <CAPpHfdvfK+Zk=MjjC1M_66+ALD+vdR6BG3quoFAZzjL6hNv-NQ@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <a.korotkov@postgrespro.ru>
	message dated "Thu, 01 Aug 2019 22:15:22 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19188.1564687723.1@sss.pgh.pa.us>
Date: Thu, 01 Aug 2019 15:28:43 -0400
Message-ID: <19189.1564687723@sss.pgh.pa.us>
Precedence: bulk

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