On Mon, Jul 18, 2022 at 3:16 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: > > I also notice that setrefs.c can elide Append and MergeAppend nodes > > too in some cases, but AFAICS costing of those node types doesn't > > take that into account. > > I took a closer look at this point and realized that in fact, > create_append_path and create_merge_append_path do attempt to account > for this. But they get it wrong! Somebody changed the rules in > setrefs.c to account for parallelism, and did not update the costing > side of things. > > The attached v2 is the same as v1 plus adding a fix for this point. > No regression test results change from that AFAICT.
The new fix looks good to me. Seems setrefs.c added a new logic to check parallel_aware when removing single-child Appends/MergeAppends in f9a74c14, but it neglected to update the related costing logic. And I can see this patch fixes the costing for that. BTW, not related to this patch, the new lines for parallel_aware check in setrefs.c are very wide. How about wrap them to keep consistent with arounding codes? Thanks Richard
