On Tue, Apr 12, 2022 at 2:57 AM bucoo@sohu.com <bucoo@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
