On 11 September 2017 at 18:55, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> 1. >>> + else if (IsA(subpath, MergeAppendPath)) >>> + { >>> + MergeAppendPath *mpath = (MergeAppendPath *) subpath; >>> + >>> + /* >>> + * If at all MergeAppend is partial, all its child plans have to be >>> + * partial : we don't currently support a mix of partial and >>> + * non-partial MergeAppend subpaths. >>> + */ >>> + if (is_partial) >>> + return list_concat(partial_subpaths, list_copy(mpath->subpaths)); >>> >>> In which situation partial MergeAppendPath is generated? Can you >>> provide one example of such path? >> >> Actually currently we don't support partial paths for MergeAppendPath. >> That code just has that if condition (is_partial) but currently that >> condition won't be true for MergeAppendPath. >> > > I think then it is better to have Assert for MergeAppend. It is > generally not a good idea to add code which we can never hit.
Done. > One more thing, I think you might want to update comment atop > add_paths_to_append_rel to reflect the new type of parallel-aware > append path being generated. In particular, I am referring to below > part of the comment: > > * Similarly it collects partial paths from > * non-dummy children to create partial append paths. > */ > static void > add_paths_to_append_rel() > Added comments. Attached revised patch v15. There is still the open point being discussed : whether to have non-parallel-aware partial Append path, or always have parallel-aware Append paths. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
ParallelAppend_v15.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers