Re: Costing elided SubqueryScans more nearly correctly

On Mon, Jul 18, 2022 at 3:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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