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 по дате отправления: