Ashutosh Bapat <ashutosh.bapat....@gmail.com> writes: > On Fri, Dec 2, 2022 at 8:25 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >> Unfortunately, I don't have an example that produces such a >> failure against HEAD. It seems certain to me that such cases >> exist, though, so I'd like to apply and back-patch the attached.
> From this comment, that I wrote back when I implemented that function, > I wonder if we thought MaterialPath wouldn't appear on the inner side > of nestloop join. But that can't be the case. Or probably we didn't > find MaterialPath being there from our tests. > * This function is currently only applied to the inner side of a nestloop > * join that is being partitioned by the partitionwise-join code. Hence, > * we need only support path types that plausibly arise in that context. > But I think it's good to have MaterialPath there. So thinking about this a bit: the reason it is okay if reparameterize_path fails is that it's not fatal. We just go on our way without making a parameterized path for that appendrel. However, if reparameterize_path_by_child fails for every available child path, we end up with "could not devise a query plan", because the partitionwise-join code is brittle and won't tolerate failure to build a parent-join path. Seems like we should be willing to fall back to a non-partitionwise join in that case. regards, tom lane