Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Fri, Nov 17, 2023 at 11:38 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> That line of argument also leads to the conclusion that it'd be
>> okay to expose info about the ordering of the CTE result to the
>> upper planner. This patch doesn't do that, and I'm not sufficiently
>> excited about the issue to go write some code. But if someone else
>> does, I think we shouldn't exclude doing it on the grounds of wanting
>> to preserve an optimization fence. The fence is sort of one-way
>> in this line of thinking: information can propagate up to the outer
>> planner level, but not down into the CTE plan.

> Exactly! Thanks for the detailed explanation.

OK. I pushed the patch after a bit more review: we can simplify
things some more by using the subroot->parse querytree for all
tests. After the previous refactoring, it wasn't buying us anything
to do some initial tests with the raw querytree. (The original
idea of that, I believe, was to avoid doing find_base_rel if we
could; but now that's not helpful.)

regards, tom lane