From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
Date: Wed, 16 Jan 2019 20:21:32 +0900
Message-ID: <5C3F13BC.9030801@lab.ntt.co.jp> (raw)
In-Reply-To: <CAExHW5ttLsVYypoWyLyyUrEa7mxpczrRkB0Oh-TuSyRy=0tOPA@mail.gmail.com>
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>
(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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: fujita.etsuro@lab.ntt.co.jp, ashutosh.bapat.oss@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
In-Reply-To: <5C3F13BC.9030801@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox