Re: paths in partitions of a dummy partitioned table

On Thu, Jul 6, 2017 at 11:35 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the
> partition relations dummy and thus doesn't set any (dummy) paths in the
> partition relations. The lack of paths in the partitions means that we can
> not use partition-wise join while joining this table with some other similarly
> partitioned table as the partitions do not have any paths that child-joins can
> use. This means that we can not create partition relations for such a join and
> thus can not consider the join to be partitioned. This doesn't matter much when
> the dummy relation is the outer relation, since the resultant join is also
> dummy. But when the dummy relation is inner relation, the resultant join is not
> dummy and can be considered to be partitioned with same partitioning scheme as
> the outer relation to be joined with other similarly partitioned table. Not
> having paths in the partitions deprives us of this future optimization.

I think it's wrong for any code to be examining the path list for a
rel marked dummy, so I would suggest approaching this from a different
direction. Given A LEFT JOIN B where Bk is dummy, I suggest
constructing the path for (AB)k by taking a path from Ak and applying
an appropriate PathTarget. You don't really need a join path at all;
a path for the non-dummy input is fine - and, in fact, better, since
it will be cheaper to execute. One problem is that it may not produce
the correct output columns. (AB) may drop some columns that were
being generated by A because they were only needed to perform the
join, and it may add additional columns taken from B. But I think
that if you take the default PathTarget for (AB) and replace
references to columns of B with NULL constants, you should be able to
apply the resulting PathTarget to a path for Ak and get a valid path
for (AB)k. Maybe there is some reason why that won't work exactly,
but I think it is probably more promising to attack the problem from
this angle than to do what you propose. Sticking dummy joins into the
query plan that are really just projecting out NULLs is not appealing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company