Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0

(2019/01/16 15:21), Ashutosh Bapat wrote:
> On Wed, Jan 16, 2019 at 11:22 AM Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@lab.ntt.co.jp>> 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