Re: Re: fix cost subqueryscan wrong parallel cost
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: "bucoo@sohu.com" <bucoo@sohu.com>
Cc: Richard Guo <guofenglinux@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-04-20T14:13:53Z
Lists: pgsql-hackers
On Wed, Apr 20, 2022 at 10:01 AM bucoo@sohu.com <bucoo@sohu.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
Commits
-
Fix rowcount estimate for SubqueryScan that's under a Gather.
- c40ba5f318f9 15.0 landed
-
Optimize order of GROUP BY keys
- db0d67db2401 15.0 cited