From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pryzby(at)telsasoft(dot)com, sanyo(dot)moura(at)tatic(dot)net, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, david(dot)rowley(at)2ndquadrant(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |
Date: | 2019-01-15 04:29:23 |
Message-ID: | CAExHW5tTrOm92CRKwF7NY19HCA9tp=QrBxEq73HS6LzUHENh4g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
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.
On Tue, Jan 15, 2019 at 8:12 AM Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
wrote:
> Fujita-san,
>
> On 2019/01/11 21:50, Etsuro Fujita wrote:
> >>> (2019/01/10 10:41), Amit Langote wrote:
> >>>> That's a loaded meaning and abusing it to mean something else can be
> >>>> challenged, but we can live with that if properly documented.
> >>>> Speaking of
> >>>> which:
> >>>>
> >>>> /* used by partitionwise joins: */
> >>>> bool consider_partitionwise_join; /* consider
> >>>> partitionwise join
> >>>> * paths? (if
> >>>> partitioned
> >>>> rel) */
> >>>>
> >>>> Maybe, mention here how it will be abused in back-branches for
> >>>> non-partitioned relations?
> >>>
> >>> Will do.
> >>
> >> Thank you.
> >
> > I know we don't yet reach a consensus on what to do in details to address
> > this issue, but for the above, how about adding comments like this to
> > set_append_rel_size(), instead of the header file:
> >
> > /*
> > * If we consider partitionwise joins with the parent rel, do the
> > same
> > * for partitioned child rels.
> > *
> > * Note: here we abuse the consider_partitionwise_join flag for
> child
> > * rels that are not partitioned, to tell
> try_partitionwise_join()
> > * that their targetlists and EC entries have been generated.
> > */
> > if (rel->consider_partitionwise_join)
> > childrel->consider_partitionwise_join = true;
> >
> > ISTM that that would be more clearer than the header file.
>
> Thanks for updating the patch. I tend to agree that it might be better to
> add such details here than in the header as it's better to keep the latter
> more stable.
>
> About the comment you added, I think we could clarify the note further as:
>
> Note: here we abuse the consider_partitionwise_join flag by setting it
> *even* for child rels that are not partitioned. In that case, we set it
> to tell try_partitionwise_join() that it doesn't need to generate their
> targetlists and EC entries as they have already been generated here, as
> opposed to the dummy child rels for which the flag is left set to false so
> that it will generate them.
>
> Maybe it's a bit wordy, but it helps get the intention across more clearly.
>
> Thanks,
> Amit
>
>
--
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-01-15 05:15:50 | Re: current_logfiles not following group access and instead follows log_file_mode permissions |
Previous Message | Alvaro Herrera | 2019-01-15 04:21:24 | Re: unique, partitioned index fails to distinguish index key from INCLUDEd columns |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Güttler | 2019-01-15 09:23:12 | Re: Detect missing combined indexes (automatically) |
Previous Message | Amit Langote | 2019-01-15 02:42:18 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |