On Wed, Apr 20, 2022 at 11:38 PM bu...@sohu.com <bu...@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. > I don't understand how that plan shape is possible. Gather requires a parallel aware subpath, so said subpath can be executed multiple times in parallel, and subquery isn't. If there is parallelism happening within a subquery the results are consolidated using Append or Gather first - and the output rows of that path entry (all subpaths of Subquery have the same ->row value per set_subquery_size_estimates), become the input tuples for Subquery, to which it then applies its selectivity multiplier and stores the final result in baserel->rows; which the costing code then examines when costing the RTE_SUBQUERY path entry. David J.
