(2019/01/16 15:21), Ashutosh Bapat wrote:
On Wed, Jan 16, 2019 at 11:22 AM Etsuro Fujita <[email protected] <mailto:[email protected]>> wrote: (2019/01/15 13:29), Ashutosh Bapat wrote: > I think, there's something better possible. Two partitioned relations > won't use partition-wise join, if their partition schemes do not match. > Partitioned relations with same partitioning scheme share > PartitionScheme pointer. PartitionScheme structure should get an extra > counter, maintaining a count of number of partitioned relations sharing > that structure. When this counter is 1, that relation is certainly not > going to participate in PWJ and thus need not have all the structure > required by PWJ set up. If we use this counter coupled with > enable_partitionwise_join flag, we can get rid of > consider_partitionwise_join flag altogether, I think.Interesting! That flag was introduced to disable PWJs when whole-row Vars are involved, as you know, so I think we need to first eliminate that limitation, to remove that flag. For that we don't need a separate flag. Do we? AFAIR, somewhere under try_partitionwise_join() we check whether PWJ is possible between two relations. That involves a bunch of checks like checking whether the relations have same bounds. Those checks should be enhanced to incorporate existence of whole-var, I think.
Yeah, that check is actually done in build_joinrel_partition_info(), which is called from build_join_rel() and build_child_join_rel() (only the latter is called from try_partitionwise_join()).
That flag is used in build_joinrel_partition_info() for that check, but as you mentioned, I think it would be possible to remove that flag, probably by checking the WRV existence from the outer_rel/inner_rel's reltarget, instead of that flag. But I'm not sure we can do that efficiently without complicating the existing code including the original PWJ one. That flag doesn't make that code complicated. I thought it would be better to not complicate that code, because disabling such PWJs would be something temporary until we support them.
Anyway, I think this would be a separate issue from the original one we discussed on this thread.
Best regards, Etsuro Fujita
