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

From Jesper Pedersen
Subject Re: speeding up planning with partitions
Date
Msg-id ce7bb7c2-8eac-0047-1e04-e771f08ad1fb@redhat.com
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
Hi Amit,

Passes check-world.

On 3/4/19 5:38 AM, Amit Langote wrote:
> See patch 0001.
> 

+* members of any appendrels we find here are added built later when

s/built//

> See patch 0002.
>

+        grouping_planner(root, false, 0.0 /* retrieve all tuples */);

Move comment out of function call.

+        if (root->simple_rte_array[childRTindex])
+            elog(ERROR, "rel %d already exists", childRTindex);
+        root->simple_rte_array[childRTindex] = childrte;
+        if (root->append_rel_array[childRTindex])
+            elog(ERROR, "child relation %d already exists", childRTindex);
+        root->append_rel_array[childRTindex] = appinfo;


Could the "if"s be made into Assert's instead ?

+ *        the    newly added bytes with zero

Extra spaces

+    if (rte->rtekind == RTE_RELATION &&    !root->contains_inherit_children)

s/TAB/space

> See patch 0003.
> 

+     * because they correspond to flattneed UNION ALL subqueries.  Especially,

s/flattneed/flatten

> See patch 0004.
> 

+     * no need to make any new entries, because anything that'd need those

Use "would" explicit

+ * this case, since it needn't be scanned.

, since it doesn't need to be scanned

> See patch 0005.
>
> See patch 0006.
>

I'll run some tests using a hash partitioned setup.

Best regards,
  Jesper


pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: query logging of prepared statements
Next
From: Shawn Debnath
Date:
Subject: Re: Refactoring the checkpointer's fsync request queue