Horton

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>

View thread View on postgr.es
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Alvaro Herrera <alvherre@2ndquadrant.com>, pryzby@telsasoft.com, sanyo.moura@tatic.net, Jeff Janes <jeff.janes@gmail.com>, david.rowley@2ndquadrant.com, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-16T05:52:15Z
Lists: pgsql-hackers, pgsql-performance 
Hi Ashutosh,

(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.

Thanks!

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