> 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.
