Re: Avoid full GIN index scan when possible
Alexander Korotkov <a.korotkov@postgrespro.ru>
From: Alexander Korotkov <a.korotkov@postgrespro.ru>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>,
Nikita Glukhov <n.gluhov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Marc Cousin <cousinmarc@gmail.com>
Date: 2019-06-29T17:27:04Z
Lists: pgsql-hackers
On Sat, Jun 29, 2019 at 1:25 PM Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > A related issue is that during costing is too late to modify cardinality > estimates, so the 'Bitmap Index Scan' will be expected to return fewer > rows than it actually returns (after ignoring the full-scan quals). > Ignoring redundant quals (the way btree does it at execution) does not > have such consequence, of course. Adjust cardinality estimates should be possible in gincostestimate(), because we call extractquery() method there. However, it seems to be quite independent issue. Number of rows returned by 'Bitmap Index Scan' doesn't vary much whether we execute GIN_SEARCH_MODE_ALL or not. The only difference is for multicolumn index, GIN_SEARCH_MODE_ALL allows to exclude NULL on one column, when normal scan is performed on another column. And we can take it into account in gincostestimate(). ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Avoid full scan of GIN indexes when possible
- 4b754d6c16e1 13.0 landed