On Sat, Jan 6, 2024 at 4:08 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Well, this explanation made sense to me: > > https://www.postgresql.org/message-id/CAMbWs4-%2BGs0HJ9ouBUb%3DqwHsGCXxG%2B92eJzLOpCkedvgtOWQ%3DQ%40mail.gmail.com > > The argument for the patch as proposed is that we should make the > mergejoin and hashjoin code paths do what the nestloop path is doing. > However, as I replied further down in that other thread, I'm not > exactly convinced that the nestloop path is doing the right thing. > I've not had time to look closer at that, though.
I don't really understand what you were saying in your response there, or what you're saying here. It seems to me that if the path is parameterized by top relids, and the assertion is verifying that a certain set of non-toprelids i.e. otherrels isn't present, then obviously the assertion is going to pass, but it's not checking what it purports to be checking. The ostensible purpose of the assertion is to check that neither side is parameterized by the other side, because a non-nestloop can't satisfy a parameterization. But with the assertion as currently formulated, it would pass even if one side *were* parameterized by the other side, because outer_paramrels and inner_paramrels would contain child relations, and the set that it was being compared to would contain only top-parents, and so they wouldn't overlap. -- Robert Haas EDB: http://www.enterprisedb.com