On Tue, Apr 12, 2022 at 2:57 AM bu...@sohu.com <bu...@sohu.com> wrote: > The cost_subqueryscan function does not judge whether it is parallel.
I don't see any reason why it would need to do that. A subquery scan isn't parallel aware. > regress > -- Incremental sort vs. set operations with varno 0 > set enable_hashagg to off; > explain (costs off) select * from t union select * from t order by 1,3; > QUERY PLAN > ---------------------------------------------------------- > Incremental Sort > Sort Key: t.a, t.c > Presorted Key: t.a > -> Unique > -> Sort > Sort Key: t.a, t.b, t.c > -> Append > -> Gather > Workers Planned: 2 > -> Parallel Seq Scan on t > -> Gather > Workers Planned: 2 > -> Parallel Seq Scan on t t_1 > to > Incremental Sort > Sort Key: t.a, t.c > Presorted Key: t.a > -> Unique > -> Sort > Sort Key: t.a, t.b, t.c > -> Gather > Workers Planned: 2 > -> Parallel Append > -> Parallel Seq Scan on t > -> Parallel Seq Scan on t t_1 > Obviously the latter is less expensive Generally it should be. But there's no subquery scan visible here. There may well be something wrong here, but I don't think that you've diagnosed the problem correctly, or explained it clearly. -- Robert Haas EDB: http://www.enterprisedb.com