| From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marc Cousin <cousinmarc(at)gmail(dot)com> |
| Subject: | Re: Avoid full GIN index scan when possible |
| Date: | 2019-06-29 17:27:04 |
| Message-ID: | CAPpHfdugwqUOfE5sw94ZKuUtU+Y97s57stA1q1AsioQido5c5A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jun 29, 2019 at 1:25 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2019-06-29 17:28:41 | Re: Avoid full GIN index scan when possible |
| Previous Message | Tom Lane | 2019-06-29 17:21:48 | Re: [HACKERS] Regression tests vs existing users in an installation |