Incorrect calculation of the total number of estimated / real rows in some parallel plans

[yhuelf]

In this plan, the inner side of the join is executed in full for each worker and the leader. This means that every process must have a private copy of the hash. Therefore, it is inappropriate to multiply the number of rows by "loops" in this case (nodes 5 and 6).

See here for further details : https://www.postgresql.org/docs/current/parallel-plans.html#PARALLEL-JOINS

[yhuelf]

Compare with the parallel hash join for the same query.

The only difference with before is a RESET enable_parallel_hash;

https://explain.dalibo.com/plan/f11gg33e19adf0dh

[yhuelf]

Same problem with a merge join, of course, as per the documentation

https://explain.dalibo.com/plan/56a23c086073a315

[MatteoGioioso]

Noticed the same, when workers are present the rows in the plan are the average returned per worker despite the number of loops.