RE: [PATCH] Resolve Parallel Hash Join Performance Issue

Thank you for the comment. Yes, I agree the alternative of using '(!parallel)', so that no need to test the bit. Will
someonesubmit patch to for it accordingly?
 

-----Original Message-----
From: Thomas Munro <thomas.munro@gmail.com> 
Sent: Thursday, January 9, 2020 6:04 PM
To: Deng, Gang <gang.deng@intel.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] Resolve Parallel Hash Join Performance Issue

On Thu, Jan 9, 2020 at 10:04 PM Deng, Gang <gang.deng@intel.com> wrote:
> Attached is a patch to resolve parallel hash join performance issue. This is my first time to contribute patch to
PostgreSQLcommunity, I referred one of previous thread as template to report the issue and patch. Please let me know if
needmore information of the problem and patch.
 

Thank you very much for investigating this and for your report.

>         HeapTupleHeaderSetMatch(HJTUPLE_MINTUPLE(node->hj_CurTuple));
>
>     changed to:
>
>         if 
> (!HeapTupleHeaderHasMatch(HJTUPLE_MINTUPLE(node->hj_CurTuple)))
>
>         {
>
>             
> HeapTupleHeaderSetMatch(HJTUPLE_MINTUPLE(node->hj_CurTuple));
>
>         }
>
>     Compared with original code, modified code can avoid unnecessary write to memory/cache.

Right, I see.  The funny thing is that the match bit is not even used in this query (it's used for right and full hash
join,and those aren't supported for parallel joins yet).  Hmm.  So, instead of the test you proposed, an alternative
wouldbe to use if (!parallel).
 
That's a value that will be constant-folded, so that there will be no branch in the generated code (see the
pg_attribute_always_inlinetrick).  If, in a future release, we need the match bit for parallel hash join because we add
parallelright/full hash join support, we could do it the way you showed, but only if it's one of those join types,
usinganother constant parameter.
 

> D. Result
>
> With the modified code, performance of hash join operation can scale better with number of threads. Here is result of
query02after patch. For example, performance improved ~2.5x when run 28 threads.
 
>
> number of thread:    1       4        8     16    28
> time used(sec):    465.1  193.1   97.9   55.9  41

Wow.  That is a very nice improvement.