pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Marc Cousin <cousinmarc@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Avoid full GIN index scan when possible
Date: Thu, 01 Aug 2019 15:28:43 -0400
Message-ID: <19189.1564687723@sss.pgh.pa.us> (raw)
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>

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





view thread (54+ messages)  latest in thread

Message-ID: <19189.1564687723@sss.pgh.pa.us>
Permalink:  ../19189.1564687723@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/19189.1564687723@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, a.korotkov@postgrespro.ru, rjuju123@gmail.com, thomas.munro@gmail.com, cousinmarc@gmail.com, tomas.vondra@2ndquadrant.com, n.gluhov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
  Subject: Re: Avoid full GIN index scan when possible
  In-Reply-To: <19189.1564687723@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox