Re: Parallel Full Hash Join - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel Full Hash Join
Date
Msg-id 1604497.1680637072@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel Full Hash Join  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Parallel Full Hash Join  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> I committed the main patch.

This left the following code in hash_inner_and_outer (joinpath.c):

        /*
         * If the joinrel is parallel-safe, we may be able to consider a
         * partial hash join.  However, we can't handle JOIN_UNIQUE_OUTER,
         * because the outer path will be partial, and therefore we won't be
         * able to properly guarantee uniqueness.  Similarly, we can't handle
         * JOIN_FULL and JOIN_RIGHT, because they can produce false null
         * extended rows.  Also, the resulting path must not be parameterized.
         */
        if (joinrel->consider_parallel &&
            save_jointype != JOIN_UNIQUE_OUTER &&
            outerrel->partial_pathlist != NIL &&
            bms_is_empty(joinrel->lateral_relids))
        {

The comment is no longer in sync with the code: this if-test used to
reject JOIN_FULL and JOIN_RIGHT, and no longer does so, but the comment
still claims it should.  Shouldn't we drop the sentence beginning
"Similarly"?  (I see that there's now one sub-section that still rejects
such cases, but it no longer seems correct to claim that they're rejected
overall.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: psql: show current user in prompt
Next
From: Nikita Malakhov
Date:
Subject: Re: SQL/JSON revisited