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 someone submit patch to for it accordingly?

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

On Thu, Jan 9, 2020 at 10:04 PM Deng, Gang <gang(dot)deng(at)intel(dot)com> wrote:
> Attached is a patch to resolve parallel hash join performance issue. This is my first time to contribute patch to PostgreSQL community, I referred one of previous thread as template to report the issue and patch. Please let me know if need more 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 would be 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_inline trick). If, in a future release, we need the match bit for parallel hash join because we add parallel right/full hash join support, we could do it the way you showed, but only if it's one of those join types, using another constant parameter.

> D. Result
>
> With the modified code, performance of hash join operation can scale better with number of threads. Here is result of query02 after 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.