| From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, arcadiy(at)gmail(dot)com, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Optimizer misses big in 10.4 with BRIN index |
| Date: | 2018-07-26 08:11:44 |
| Message-ID: | CAE2gYzzgQP3tMMPaR-xPCrTpC8_afGnBOO3EaD6bDEQBn3UNQA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Isn't the 23040 just the totalpages * 10 per `return totalpages * 10;`
> in bringetbitmap()?
Yes, it is just confusing. The correct value is on one level up of
the tree. It is 204 + 4404 rows removed by index recheck = 4608, so
the estimate is not only 150x but 733x off :(.
The sequential scan plan shows 204 + 1125498 rows removed by filter =
1125702 as the actual table size. However the former plan estimates
to get 3377106 rows from the index. That is 3x of the table size.
The selectivity estimation cannot be greater than 1. If I am not
missing anything, the general statistics of this table should be
seriously outdated.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ibrar Ahmed | 2018-07-26 08:23:37 | Re: Log query parameters for terminated execute |
| Previous Message | Oleksandr Shulgin | 2018-07-26 07:32:47 | Re: How can we submit code patches that implement our (pending) patents? |