Re: Missing MaterialPath support in reparameterize_path_by_child

Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> On Fri, Dec 2, 2022 at 8:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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