Re: Parallel bitmap heap scan

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel bitmap heap scan
Date: 2016-10-19 04:13:10
Message-ID: CAFiTN-v28GzqV3zneA5UpxtN=WGFLKiyaSse4xxXdmv+abKfDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 18, 2016 at 1:42 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> But what's the impact on performance? Presumably parallel bitmap heap
> scan was already slower than the non-parallel version, and that commit
> presumably widens the gap. Seems like something to worry about...

I have checked the performance in my local machine and there is no
impact on the gap.
If you see the explain analyze output of all queries which got
benefited which parallel bitmap map heap scan, BitmapIndex node is
taking very less time compare to BitmapHeap.

Actual execution time on head (before efficient hash table patch)
BitmapHeapNode BitmapIndexNode
Q6 38997 6951
Q14 14516 569
Q15 28530 1442

Out of 4 queries, Q4 is converted from parallel seqscan to parallel
bitmap scan so no impact.
Q14, Q15 time spent in BitmapIndex node is < 5% of time spent in
BitmapHeap Node. Q6 it's 20% but I did not see much impact on this in
my local machine. However I will take the complete performance reading
and post the data on my actual performance machine.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2016-10-19 04:17:35 Re: Parallel bitmap heap scan
Previous Message Tom Lane 2016-10-19 04:01:01 Change of schedule for the next batch of PG update releases