Re: Re: fix cost subqueryscan wrong parallel cost

> Generally it should be. But there's no subquery scan visible here.
I wrote a patch for distinct/union and aggregate support last year(I want restart it again).
https://www.postgresql.org/message-id/2021091517250848215321%40sohu.com
If not apply this patch, some parallel paths will naver be selected.

> Some debugging work shows that the second path is generated but then
> fails when competing with the first path. So if there is something
> wrong, I think cost calculation is the suspicious point.
Maybe, I will check it again.

> Not related to this topic but I noticed another problem from the plan.
> Note the first Sort node which is to unique-ify the result of the UNION.
> Why cannot we re-arrange the sort keys from (a, b, c) to (a, c, b) so
> that we can avoid the second Sort node?
This is a regress test, just for test Incremental Sort plan.