RE: speeding up planning with partitions - Mailing list pgsql-hackers

From Imai, Yoshikazu
Subject RE: speeding up planning with partitions
Date
Msg-id 0F97FA9ABBDBE54F91744A9B37151A512AFE7A@g01jpexmbkw24
Whole thread Raw
In response to Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
Amit-san,

On Mon, Mar 18, 2019 at 9:56 AM, Amit Langote wrote:
> On 2019/03/15 14:40, Imai, Yoshikazu wrote:
> > Amit-san,
> >
> > I have another little comments about v31-patches.
> >
> > * We don't need is_first_child in inheritance_planner().
> >
> > On Fri, Mar 8, 2019 at 9:18 AM, Amit Langote wrote:
> >> On 2019/03/08 16:16, Imai, Yoshikazu wrote:
> >>> I attached the diff of modification for v26-0003 patch which also
> >> contains some refactoring.
> >>> Please see if it is ok.
> >>
> >> I like the is_first_child variable which somewhat improves
> >> readability, so updated the patch to use it.
> >
> > I noticed that detecting first child query in inheritance_planner()
> is already done by "final_rtable == NIL"
> >
> >         /*
> >          * If this is the first non-excluded child, its post-planning
> rtable
> >          * becomes the initial contents of final_rtable; otherwise,
> append
> >          * just its modified subquery RTEs to final_rtable.
> >          */
> >         if (final_rtable == NIL)
> >
> > So I think we can use that instead of using is_first_child.
> 
> That's a good suggestion.  One problem I see with that is that
> final_rtable is set only once we've found the first *non-dummy* child.

Ah... I overlooked that.

> So, if all the children except the last one are dummy, we'd end up never
> reusing the source child objects.  Now, if final_rtable was set for the
> first child irrespective of whether it turned out to be dummy or not,
> which it seems OK to do, then we can implement your suggestion.

I thought you mean we can remove or move below code to under setting final_rtable.

        /*
         * If this child rel was excluded by constraint exclusion, exclude it
         * from the result plan.
         */
        if (IS_DUMMY_REL(sub_final_rel))
            continue;

It seems logically ok, but I also thought there are the case where useless process happens.

If we execute below update statement, final_rtable would be unnecessarily expanded by adding placeholder.

* partition table rt with 1024 partitions.
* partition table pt with 2 partitions.
* update rt set c = ss.c from ( select b from pt union all select b + 3 from pt) ss where a = 1024 and rt.b = ss.b;


After all, I think it might be better to use is_first_child because the meaning of is_first_child and final_rtable is
different.
is_first_child == true represents that we currently processing first child query and final_rtable == NIL represents we
didn'tfind first non-excluded child query.
 

--
Yoshikazu Imai

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rare SSL failures on eelpout
Next
From: Haribabu Kommi
Date:
Subject: Re: Libpq support to connect to standby server as priority