Thread: Simplify create_merge_append_path a bit for clarity
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
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
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
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
Thanks
Richard
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