Re: Re: fix cost subqueryscan wrong parallel cost
bucoo <bucoo@sohu.com>
From: "bucoo@sohu.com" <bucoo@sohu.com>
To: robertmhaas <robertmhaas@gmail.com>
Cc: "Richard Guo" <guofenglinux@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-04-21T06:38:22Z
Lists: pgsql-hackers
> > 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. I checked some regress test, Sometimes subquery scan have filter, so path->subpath->row guaranteed *not* to be equal to baserel->rows. If the first patch is false, I don't known how to fix this, looks like need someone's help.
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