On Fri, Jun 30, 2023 at 11:00 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Richard Guo <guofengli...@gmail.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
