Re: FailedAssertion on partprune
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Jaime Casanova <jaime.casanova@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-17T06:58:23Z
Lists: pgsql-hackers
On 14 August 2018 at 09:23, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Aug 11, 2018 at 9:16 AM, David Rowley > <david.rowley@2ndquadrant.com> wrote: >> I started debugging this to see where things go wrong. I discovered >> that add_paths_to_append_rel() is called yet again from >> apply_scanjoin_target_to_paths() and this is where it's all going >> wrong. The problem is that the gather paths have been tagged onto the >> partial paths by this time, so accumulate_append_subpath() has no code >> to look through those to fetch the Append/MergeAppend subpaths, so it >> just appends the entire path to the subpaths List. This all worked >> before 96030f9a481. This commit moved where generate_gather_paths() is >> called. > > I'm baffled as to why looking through Gather to find > Append/MergeAppend subpaths would ever be a sane thing to do. Can you explain why it's less sane than what the current code is doing? Below a Gather there will be partial paths, but we can also get those in a Parallel Append, which the accumulate_append_subpath() code already attempts to handle. If the Gather Path is there already then I guess one difference would be that the caller would need to ensure that another Gather path is placed below the Parallel Append again. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Remove bogus Assert in make_partitionedrel_pruneinfo().
- 69d0e7e6b81d 11.0 landed
- 59ef49d26d2f 12.0 landed
-
LLVMJIT: Adapt to API changes in gdb and perf support.
- 1b957e59b92d 11.0 cited
-
Rewrite the code that applies scan/join targets to paths.
- 11cf92f6e2e1 11.0 cited