Hi Tom,
On Fri, Dec 2, 2022 at 8:25 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Whilst fooling with my outer-join-aware-Vars patch, I tripped
> across a multi-way join query that failed with
> ERROR: could not devise a query plan for the given query
> when enable_partitionwise_join is on.
>
> I traced that to the fact that reparameterize_path_by_child()
> omits support for MaterialPath, so that if the only surviving
> path(s) for a child join include materialization steps, we'll
> fail outright to produce a plan for the parent join.
>
> 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.
>
> I'm suspicious now that reparameterize_path() should be
> extended likewise, but I don't really have any hard
> evidence for that.
I think we need it there since the scope of paths under appendrel has
certainly expanded a lot because of partitioned table optimizations.
The patch looks good to me.
--
Best Wishes,
Ashutosh Bapat
