Re: Slow query: bitmap scan troubles
От | Claudio Freire |
---|---|
Тема | Re: Slow query: bitmap scan troubles |
Дата | |
Msg-id | CAGTBQpaKOfZs+qy+S7CCPcTg7PYOrwgcQAXgWV88cQTn-BFstg@mail.gmail.com обсуждение исходный текст |
Ответ на | Slow query: bitmap scan troubles (<postgresql@foo.me.uk>) |
Ответы |
Re: Slow query: bitmap scan troubles
Re: Slow query: bitmap scan troubles |
Список | pgsql-performance |
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. First, make sure caching isn't interfering with your results. Run each query several times. Then, if the difference persists, you may have to tweak effective_cache_size first, maybe random_page_cost too, to better match your I/O subsystem's actual performance
В списке pgsql-performance по дате отправления: