Re: Re: fix cost subqueryscan wrong parallel cost
От | Robert Haas |
---|---|
Тема | Re: Re: fix cost subqueryscan wrong parallel cost |
Дата | |
Msg-id | CA+TgmobdXCGHrQV2Mhq+WeqTsqLtoNq-ygfjYz4FVuBFLQNc8w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: fix cost subqueryscan wrong parallel cost ("bucoo@sohu.com" <bucoo@sohu.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: