Horton

Re: Parallel Full Hash Join

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Ian Lawrence Barwick <barwick@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, vignesh C <vignesh21@gmail.com>, Greg Nancarrow <gregn4422@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-04-09T23:33:30Z
Lists: pgsql-hackers 
On Sat, Apr 08, 2023 at 02:19:54PM -0400, Melanie Plageman wrote:
> Another worker attached to the batch barrier, saw that it was in
> PHJ_BATCH_SCAN, marked it done and detached. This is fine.
> BarrierArriveAndDetachExceptLast() is meant to ensure no one waits
> (deadlock hazard) and that at least one worker stays to do the unmatched
> scan. It doesn't hurt anything for another worker to join and find out
> there is no work to do.
> 
> We should simply delete this assertion.

I have added an open item about that.  This had better be tracked.
--
Michael

Commits

  1. Remove overzealous assertion from PHJ.

  2. Remove comment obsoleted by 11c2d6fd.

  3. Parallel Hash Full Join.

  4. Improve the naming of Parallel Hash Join phases.

  5. Update the names of Parallel Hash Join phases.

  6. Add BarrierArriveAndDetachExceptLast().

  7. Mop-up for wait event naming issues.

  8. Push tuple limits through Gather and Gather Merge.