Re: Parallel Full Hash Join
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-29T02:28:12Z
Lists: pgsql-hackers
Attachments
- v4-0001-Parallel-Hash-Full-Right-Join.patch (text/x-patch) patch v4-0001
On Mon, Dec 28, 2020 at 9:49 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > On Thu, Nov 5, 2020 at 7:34 AM Melanie Plageman > <melanieplageman@gmail.com> wrote: > > I've attached a patch with the corrections I mentioned upthread. > > I've gone ahead and run pgindent, though, I can't say that I'm very > > happy with the result. > > > > I'm still not quite happy with the name > > BarrierArriveAndDetachExceptLast(). It's so literal. As you said, there > > probably isn't a nice name for this concept, since it is a function with > > the purpose of terminating parallelism. > > You sent in your patch, v3-0001-Support-Parallel-FOJ-and-ROJ.patch to > pgsql-hackers on Nov 5, but you did not post it to the next > CommitFest[1]. If this was intentional, then you need to take no > action. However, if you want your patch to be reviewed as part of the > upcoming CommitFest, then you need to add it yourself before > 2021-01-01 AOE[2]. Also, rebasing to the current HEAD may be required > as almost two months passed since when this patch is submitted. Thanks > for your contributions. Thanks for this reminder Sawada-san. I had some feedback I meant to post in November but didn't get around to: +bool +BarrierArriveAndDetachExceptLast(Barrier *barrier) I committed this part (7888b099). I've attached a rebase of the rest of Melanie's v3 patch. + WAIT_EVENT_HASH_BATCH_PROBE, That new wait event isn't needed (we can't and don't wait). * PHJ_BATCH_PROBING -- all probe - * PHJ_BATCH_DONE -- end + + * PHJ_BATCH_DONE -- queries not requiring inner fill done + * PHJ_BATCH_FILL_INNER_DONE -- inner fill completed, all queries done Would it be better/tidier to keep _DONE as the final phase? That is, to switch around these two final phases. Or does that make it too hard to coordinate the detach-and-cleanup logic? +/* + * ExecPrepHashTableForUnmatched + * set up for a series of ExecScanHashTableForUnmatched calls + * return true if this worker is elected to do the unmatched inner scan + */ +bool +ExecParallelPrepHashTableForUnmatched(HashJoinState *hjstate) Comment name doesn't match function name.
Commits
-
Remove overzealous assertion from PHJ.
- b37d051b0e59 16.0 landed
-
Remove comment obsoleted by 11c2d6fd.
- f303ec6210c4 16.0 landed
-
Parallel Hash Full Join.
- 11c2d6fdf5af 16.0 landed
-
Improve the naming of Parallel Hash Join phases.
- 8fba928fd788 16.0 landed
-
Update the names of Parallel Hash Join phases.
- 378802e3713c 14.0 landed
-
Add BarrierArriveAndDetachExceptLast().
- 7888b0999488 14.0 landed
-
Mop-up for wait event naming issues.
- 3048898e73c7 13.0 cited
-
Push tuple limits through Gather and Gather Merge.
- 3452dc5240da 11.0 cited