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-21T12:00:30Z
Lists: pgsql-hackers
On Thu, Apr 21, 2022 at 2:38 AM bucoo@sohu.com <bucoo@sohu.com> wrote: > > 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. Please fix your mailer so that it doesn't send me a bounce message every time I reply to one of your messages on list. I don't know how to fix this right now either, then; maybe I or someone else will have a good idea later. -- 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