Re: Re: fix cost subqueryscan wrong parallel cost

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "bucoo(at)sohu(dot)com" <bucoo(at)sohu(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: fix cost subqueryscan wrong parallel cost
Date: 2022-04-20 14:13:53
Message-ID: CA+TgmobdXCGHrQV2Mhq+WeqTsqLtoNq-ygfjYz4FVuBFLQNc8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 20, 2022 at 10:01 AM bucoo(at)sohu(dot)com <bucoo(at)sohu(dot)com> wrote:
> for now fuction cost_subqueryscan always using *total* rows even parallel
> path. like this:
>
> Gather (rows=30000)
> Workers Planned: 2
> -> Subquery Scan (rows=30000) -- *total* rows, should be equal subpath
> -> Parallel Seq Scan (rows=10000)

OK, that's bad.

> Maybe the codes:
>
> /* Mark the path with the correct row estimate */
> if (param_info)
> path->path.rows = param_info->ppi_rows;
> else
> path->path.rows = baserel->rows;
>
> should change to:
>
> /* Mark the path with the correct row estimate */
> if (path->path.parallel_workers > 0)
> path->path.rows = path->subpath->rows;
> else if (param_info)
> path->path.rows = param_info->ppi_rows;
> else
> path->path.rows = baserel->rows;

Suppose parallelism is not in use and that param_info is NULL. Then,
is path->subpath->rows guaranteed to be equal to baserel->rows? If
yes, then we don't need to a three-part if statement as you propose
here and can just change the "else" clause to say path->path.rows =
path->subpath->rows. If no, then your change gives the wrong answer.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-04-20 14:15:57 Re: Bad estimate with partial index
Previous Message Robert Haas 2022-04-20 14:08:36 Re: generalized conveyor belt storage