Re: fix cost subqueryscan wrong parallel cost
bucoo <bucoo@sohu.com>
From: "bucoo" <bucoo@sohu.com>
To: "'Robert Haas'" <robertmhaas@gmail.com>
Cc: "'Richard Guo'" <guofenglinux@gmail.com>, "'pgsql-hackers'" <pgsql-hackers@postgresql.org>
Date: 2022-04-22T03:35:43Z
Lists: pgsql-hackers
> > > 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. This message send using Outlook. > I don't know how to fix this right now either, then; maybe I or > someone else will have a good idea later. I don't known too.
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