Re: Slow query: bitmap scan troubles
От | Claudio Freire |
---|---|
Тема | Re: Slow query: bitmap scan troubles |
Дата | |
Msg-id | CAGTBQpbqzBf5545-qxdLQHbLyBBOvxn3hEtjQmqEp+UJPKsSrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Slow query: bitmap scan troubles (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Slow query: bitmap scan troubles
Re: Slow query: bitmap scan troubles |
Список | pgsql-performance |
On Tue, Dec 4, 2012 at 2:22 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Tue, Dec 4, 2012 at 7:27 AM, Claudio Freire <klaussfreire@gmail.com> wrote: >> On Tue, Dec 4, 2012 at 12:06 PM, <postgresql@foo.me.uk> wrote: >>> Slow version with bitmapscan enabled: http://explain.depesz.com/s/6I7 >>> Fast version with bitmapscan disabled: http://explain.depesz.com/s/4MWG >> >> If you check the "fast" plan, it has a higher cost compared against >> the "slow" plan. >> >> The difference between cost estimation and actual cost of your >> queries, under relatively precise row estimates, seems to suggest your >> e_c_s or r_p_c aren't a reflection of your hardware's performance. > > But the row estimates are not precise at the top of the join/filter. > It thinks there will 2120 rows, but there are only 11. Ah... I didn't spot that one...
В списке pgsql-performance по дате отправления: