Re: fix cost subqueryscan wrong parallel cost

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