Re: Slow query: bitmap scan troubles
От | |
---|---|
Тема | Re: Slow query: bitmap scan troubles |
Дата | |
Msg-id | 096f01cdd247$722264a0$56672de0$@foo.me.uk обсуждение исходный текст |
Ответ на | Re: Slow query: bitmap scan troubles (Claudio Freire <klaussfreire@gmail.com>) |
Ответы |
Re: Slow query: bitmap scan troubles
Re: Slow query: bitmap scan troubles Re: Slow query: bitmap scan troubles |
Список | pgsql-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... Yes, you are right there - this is probably a slightly atypical query of this sort actually, 2012 is a pretty good guess. On Claudio's suggestion I have found lots more things to read up on and am eagerly awaiting 6pm when I can bring the DB down and start tweaking. The effective_work_mem setting is going from 6Gb->88Gb which I think will make quite a difference. I still can't quite wrap around my head why accessing an index is expected to use more disk access than doing a bitmap scan of the table itself, but I guess it does make a bit of sense if postgres assumes the table is more likely to be cached. It's all quite, quite fascinating :) I'll let you know how it goes. - Phil
В списке pgsql-performance по дате отправления: