Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)
От | Andres Freund |
---|---|
Тема | Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376) |
Дата | |
Msg-id | 20161115192802.jfbec5s6ougxwicp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376) (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)
Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376) |
Список | pgsql-hackers |
Hi Dilip, thanks for noticing that one. On 2016-11-09 21:17:22 +0530, Dilip Kumar wrote: > While testing bitmap performance, I have observed that some of the > TPCH queries taking huge time in BitmapIndexScan node, when there are > lossy pages. It's not really related to lossy pages, it's just that due to deletions / insertions a lot more "shapes" of the hashtable are hit. I suspect that this is with parallelism disabled? Without that the query ends up using a parallel sequential scan for me. I've a working fix for this, and for a similar issue Robert found. I'm still playing around with it, but basically the fix is to make the growth policy a bit more adaptive. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: