Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

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