Re: FailedAssertion on partprune - Mailing list pgsql-hackers

From David Rowley
Subject Re: FailedAssertion on partprune
Date
Msg-id CAKJS1f9oKnvBODDVYY2zQ2uv5mWr9ZCSd+9aQ8um5y_zfEaE1Q@mail.gmail.com
Whole thread Raw
In response to Re: FailedAssertion on partprune  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: FailedAssertion on partprune
List 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


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: FailedAssertion on partprune
Next
From: Tatsuro Yamada
Date:
Subject: Re: Fix help option of contrib/oid2name