Thread: Simplify create_merge_append_path a bit for clarity

Simplify create_merge_append_path a bit for clarity

From
Richard Guo
Date:
As explained in the comments for generate_orderedappend_paths, we don't
currently support parameterized MergeAppend paths, and it doesn't seem
like going to change anytime soon.  Based on that,  we could simplify
create_merge_append_path a bit, such as set param_info to NULL directly
rather than call get_appendrel_parampathinfo() for it.  We already have
an Assert on that in create_merge_append_plan.

I understand that the change would not make any difference for
performance, it's just for clarity's sake.

Thanks
Richard
Attachment

Re: Simplify create_merge_append_path a bit for clarity

From
Alena Rybakina
Date:
Hi!

On 11.08.2023 05:31, Richard Guo wrote:
> As explained in the comments for generate_orderedappend_paths, we don't
> currently support parameterized MergeAppend paths, and it doesn't seem
> like going to change anytime soon.  Based on that,  we could simplify
> create_merge_append_path a bit, such as set param_info to NULL directly
> rather than call get_appendrel_parampathinfo() for it.  We already have
> an Assert on that in create_merge_append_plan.
>
> I understand that the change would not make any difference for
> performance, it's just for clarity's sake.

I agree with you, and we can indeed directly set the param_info value to 
NULL, and there are enough comments here to explain.

I didn't find anything else to add in your patch.

-- 
Regards,
Alena Rybakina




Re: Simplify create_merge_append_path a bit for clarity

From
Richard Guo
Date:

On Tue, Oct 24, 2023 at 6:00 PM Alena Rybakina <lena.ribackina@yandex.ru> wrote:
I agree with you, and we can indeed directly set the param_info value to
NULL, and there are enough comments here to explain.

I didn't find anything else to add in your patch.

Thanks for reviewing this patch!

Thanks
Richard

Re: Simplify create_merge_append_path a bit for clarity

From
Richard Guo
Date:
On Fri, Jul 26, 2024 at 1:28 PM Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
> Is there a reason you don't want to remove the required_outer
> parameter altogether? I guess because it is such a common pattern to
> pass it?

I think it's best to keep this parameter unchanged to maintain
consistency with other functions that create path nodes in pathnode.c.

> Do you think it is worth keeping this assertion?:
>
> -
> -        /* All child paths must have same parameterization */
> -        Assert(bms_equal(PATH_REQ_OUTER(subpath), required_outer));
>
> I understand any failure would trigger one of the prior asserts
> instead, but it does communicate an extra requirement, and there is no
> cost.

I don't think it's a good idea to keep this Assert: with this change
it becomes redundant.

> But I'd be fine with committing this patch as-is.

I've pushed this patch.  Thanks for review.

Thanks
Richard