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

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>

From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-16T11:21:32Z
Lists: pgsql-hackers, pgsql-performance
(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



Commits

  1. Postpone generating tlists and EC members for inheritance dummy children.

  2. Allow direct lookups of AppendRelInfo by child relid