Re: speeding up planning with partitions

Поиск
Список
Период
Сортировка
От Jesper Pedersen
Тема Re: speeding up planning with partitions
Дата
Msg-id ce7bb7c2-8eac-0047-1e04-e771f08ad1fb@redhat.com
обсуждение исходный текст
Ответ на Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: speeding up planning with partitions
Список 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 по дате отправления:

Предыдущее
От: Arthur Zakirov
Дата:
Сообщение: Re: query logging of prepared statements
Следующее
От: Shawn Debnath
Дата:
Сообщение: Re: Refactoring the checkpointer's fsync request queue