Re: Wrong results from Parallel Hash Full Join
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Richard Guo <guofenglinux@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-06-12T03:24:24Z
Lists: pgsql-hackers
On Wed, Jun 07, 2023 at 05:16:12PM -0400, Melanie Plageman wrote: > On Fri, May 19, 2023 at 8:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Considering that this is a parallel plan, I don't think there's any >> mystery about why an ORDER-BY-less query might have unstable output >> order; the only mystery is why more of the buildfarm hasn't failed. >> Can we just add "ORDER BY t1.id" to this query? It looks like you >> get the same PHJ plan, although now underneath Sort/Gather Merge. > > Yes, this was an oversight on my part. Attached is the patch that does > just what you suggested. Confirmed that adding an ORDER BY adds a Sort node between a Gather Merge and a Parallel Hash Full Join, not removing coverage. This has fallen through the cracks and conchuela has failed again today, so I went ahead and applied the fix on HEAD. Thanks! -- Michael
Commits
-
Fix instability in regression test for Parallel Hash Full Join
- 3e8da50244a8 16.0 landed