Re: Avoid full GIN index scan when possible
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2019-08-01T19:28:43Z
Lists: 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
Commits
-
Avoid full scan of GIN indexes when possible
- 4b754d6c16e1 13.0 landed