On Tue, Jan 24, 2017 at 10:18 AM, Dilip Kumar <dilipbal...@gmail.com> wrote: > I have changed as per the comments. 0002 and 0003 are changed, 0001 is > still the same.
2 days back my colleague Rafia, reported one issue (offlist) that
parallel bitmap node is not scaling as good as other nodes e.g
parallel sequence scan and parallel index scan.
After some perf analysis, I found that there was one unconditional
spin lock in parallel bitmap patch which we were taking for checking
the prefetch target. Basically, we were always taking the lock and
checking the prefetch_target is reached to prefetch_maximum. So even
after it will reach to prefetch_maximum we will acquire the lock and
check after every tuple. I have changed that logic, now I will check
the condition first if we need to increase the target then will take
the lock and recheck the condition.
There is just one line change in 0003 compared to older version, all
other patches are the same.
Some performance data to show that new parallel bitmap patch performs
way better than the previous version.
TPCH scale 20, work_mem 64MB, shared buffers 8GB (4 workers)
machine intel 8 socket machine
v13(time in ms) v14 (time in ms)
Q6 37065.841 18202.903
Q14 15229.569 11341.121
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
0001-opt-parallelcost-refactoring-v14.patch
Description: Binary data
0002-hash-support-alloc-free-v14.patch
Description: Binary data
0003-parallel-bitmap-heap-scan-v14.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
