Re: Assert !bms_overlap(joinrel->relids, required_outer)

On Fri, Jun 30, 2023 at 11:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > I think it just makes these two assertions meaningless to skip it for
> > non-nestloop joins if the input paths are for otherrels, because paths
> > would never be parameterized by the member relations. So these two
> > assertions would always be true for otherrel paths. I think this is why
> > we have not noticed any problem by now.
>
> After studying this some more, I think that maybe it's the "run
> parameterization tests on the parent relids" bit that is misguided.
> I believe the way it's really working is that all paths arriving
> here are parameterized by top parents, because that's the only thing
> we generate to start with. A path can only become parameterized
> by an otherrel when we apply reparameterize_path_by_child to it.
> But the only place that happens is in try_nestloop_path itself
> (or try_partial_nestloop_path), and then we immediately wrap it in
> a nestloop join node, which becomes a child of an append that's
> forming a partitionwise join. The partitionwise join as a
> whole won't be parameterized by any child rels. So I think that
> a path that's parameterized by a child rel can't exist "in the wild"
> in a way that would allow it to get fed to one of the try_xxx_path
> functions. This explains why the seeming oversights in the merge
> and hash cases aren't causing a problem.
>
> If this theory is correct, we could simplify try_nestloop_path a
> bit. I doubt the code savings would matter, but maybe it's
> worth changing for clarity's sake.

Yeah, I think this theory is correct that all paths arriving at
try_xxx_path are parameterized by top parents. But I do not get how to
simplify try_nestloop_path on the basis of that. Would you please
elaborate on that?

Thanks
Richard