Message-ID: <5C3F13BC.9030801@lab.ntt.co.jp>
Date: Wed, 16 Jan 2019 20:21:32 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: Re: Query with high planning time at version 11.1 compared versions
 10.5 and 11.0
References: <8db4eca8-6e76-70ff-f934-e0228a1cc298@lab.ntt.co.jp>
 <20181206075726.pig32e6thltb56hr@alvherre.pgsql>
 <CAExHW5umxU5FOoT8FBcqp-GWKMtZhnuEy7U6bNH8QfzvYwUgEQ@mail.gmail.com>
 <CAExHW5uFwP_1N7RV6s8piQBvygGH+rppS60nFNHB9DKEM04ShA@mail.gmail.com>
 <5C34846E.9090600@lab.ntt.co.jp>
 <96720c99-ffa0-01ad-c594-0504c8eda708@lab.ntt.co.jp>
 <5C35D912.8040200@lab.ntt.co.jp>
 <7354b5bf-5932-4c0c-81ee-d9550de18995@lab.ntt.co.jp>
 <5C36E105.2020902@lab.ntt.co.jp>
 <dd1de042-dca5-cfb9-bc66-2e39020fbf6a@lab.ntt.co.jp>
 <5C38910B.8010901@lab.ntt.co.jp>
 <a5c087d0-9ecc-1315-24d2-6303d14a6116@lab.ntt.co.jp>
 <CAExHW5tTrOm92CRKwF7NY19HCA9tp=QrBxEq73HS6LzUHENh4g@mail.gmail.com>
 <5C3EC68F.8030202@lab.ntt.co.jp>
 <CAExHW5ttLsVYypoWyLyyUrEa7mxpczrRkB0Oh-TuSyRy=0tOPA@mail.gmail.com>
In-Reply-To: 
 <CAExHW5ttLsVYypoWyLyyUrEa7mxpczrRkB0Oh-TuSyRy=0tOPA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Precedence: bulk

(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