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

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

On Tue, Mar 5, 2019 at 0:51 AM, Amit Langote wrote:
> Hi Jesper,
> 
> Thanks for the review.  I've made all of the changes per your comments
> in my local repository.  I'll post the updated patches after diagnosing
> what I'm suspecting a memory over-allocation bug in one of the patches.
> If you configure build with --enable-cassert, you'll see that throughput
> decreases as number of partitions run into many thousands, but it doesn't
> when asserts are turned off.
> 
> On 2019/03/05 1:20, Jesper Pedersen wrote:
> > I'll run some tests using a hash partitioned setup.
> 
> Thanks.

I've also done code review of 0001 and 0002 patch so far.

[0001]
1. Do we need to open/close a relation in add_appendrel_other_rels()? 

+    if (rel->part_scheme)
     {
-        ListCell   *l;
    ...
-        Assert(cnt_parts == nparts);
+        rel->part_rels = (RelOptInfo **)
+                palloc0(sizeof(RelOptInfo *) * rel->nparts);
+        relation = table_open(rte->relid, NoLock);
     }

+    if (relation)
+        table_close(relation, NoLock);


2. We can sophisticate the usage of Assert in add_appendrel_other_rels().

+    if (rel->part_scheme)
     {
    ...
+        rel->part_rels = (RelOptInfo **)
+                palloc0(sizeof(RelOptInfo *) * rel->nparts);
+        relation = table_open(rte->relid, NoLock);
     }
  ...
+    i  = 0;
+    foreach(l, root->append_rel_list)
+    {
    ...
+        if (rel->part_scheme != NULL)
+        {
+            Assert(rel->nparts > 0 && i < rel->nparts);
+            rel->part_rels[i] = childrel;
+        }
+
+        i++;

as below;

+    if (rel->part_scheme)
     {
    ...
    Assert(rel->nparts > 0);
+        rel->part_rels = (RelOptInfo **)
+                palloc0(sizeof(RelOptInfo *) * rel->nparts);
+        relation = table_open(rte->relid, NoLock);
     }
  ...
+    i  = 0;
+    foreach(l, root->append_rel_list)
+    {
    ...
+        if (rel->part_scheme != NULL)
+        {
+            Assert(i < rel->nparts);
+            rel->part_rels[i] = childrel;
+        }
+
+        i++;


[0002]
3. If using variable like is_source_inh_expansion, the code would be easy to read. (I might mistakenly understand
root->simple_rel_array_size> 0 means source inheritance expansion though.)
 

In expand_inherited_rtentry() and expand_partitioned_rtentry():

+         * Expand planner arrays for adding the child relations.  Can't do
+         * this if we're not being called from query_planner.
+         */
+        if (root->simple_rel_array_size > 0)
+        {
+            /* Needed when creating child RelOptInfos. */
+            rel = find_base_rel(root, rti);
+            expand_planner_arrays(root, list_length(inhOIDs));
+        }

+            /* Create the otherrel RelOptInfo too. */
+            if (rel)
+                (void) build_simple_rel(root, childRTindex, rel);

would be:

+         * Expand planner arrays for adding the child relations.  Can't do
+         * this if we're not being called from query_planner.
+         */
+        if (is_source_inh_expansion)
+        {
+            /* Needed when creating child RelOptInfos. */
+            rel = find_base_rel(root, rti);
+            expand_planner_arrays(root, list_length(inhOIDs));
+        }

+            /* Create the otherrel RelOptInfo too. */
+            if (is_source_inh_expansion)
+                (void) build_simple_rel(root, childRTindex, rel);


4. I didn't see much carefully, but should the introduction of contains_inherit_children be in 0003 patch...?


I'll continue to do code review of rest patches.


--
Yoshikazu Imai 


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Delay locking partitions during query execution
Next
From: Andres Freund
Date:
Subject: Re: Inheriting table AMs for partitioned tables