On Thu, Jul 6, 2017 at 11:35 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
