On Fri, Dec 2, 2022 at 9:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
> > On Fri, Dec 2, 2022 at 8:25 AM Tom Lane <tgl@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
partition-wise join should be willing to fallback to non-partitionwise
join in such a case. After spending a few minutes with the code, I
think generate_partitionwise_join_paths() should not call
set_cheapest() is the pathlist of the child is NULL and should just
wind up and avoid adding any path.
--
Best Wishes,
Ashutosh Bapat
