RE: speeding up planning with partitions - Mailing list pgsql-hackers
From | Imai, Yoshikazu |
---|---|
Subject | RE: speeding up planning with partitions |
Date | |
Msg-id | 0F97FA9ABBDBE54F91744A9B37151A51213266@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 |
Hi Amit, On Tue, Nov 13, 2018 at 10:29 PM, Amit Langote wrote: > On 2018/11/12 13:35, Imai, Yoshikazu wrote: > > adjust_appendrel_attrs_multilevel for leaf1: root -> sub1 -> leaf1 > > adjust_appendrel_attrs_multilevel for leaf2: root -> sub1 -> leaf2 > > Ah, I see what you mean. > > The root -> sub1 translation will be repeated for each leaf partition > if done via adjust_appendrel_attrs_multilevel. On the other hand, if > we could do the root to sub1 translation once and pass it to the recursive > call using sub1 as the parent. > > I've changed the patch use adjust_appendrel_attrs. > > > Since it is difficult to explain my thoughts with words, I will show > > the performance degration case. > > > > Partition tables are below two sets. > > [ ... ] > > > Create a generic plan of updation or deletion. > > > > [create a delete generic plan] > > set plan_cache_mode = 'force_generic_plan'; prepare delete_stmt(int) > > as delete from rt where b = $1; execute delete_stmt(1); > > [ ... ] > > > How amount of memory is used with above tests is... > > > > without v5 patches, Set1: 242MB > > without v5 patches, Set2: 247MB > > with v5 patches, Set1: 420MB > > with v5 patches, Set2: 820MB > > Although I didn't aim to fix planning for the generic plan case where > no pruning occurs, the above result is not acceptable. That is, the new > implementation of inheritance update/delete planning shouldn't consume > more memory than the previous. In fact, it should've consumed less, > because the patch claims that it gets rid of redundant processing per > partition. > > I understood why update/delete planning consumed more memory with the > patch. It was due to a problem with the patch that modifies inheritance > update/delete planning. The exact problem was that the query tree would > be translated (hence copied) *twice* for every partition! First during > query planning where the query tree would be translated to figure out > a targetlist for partitions and then again before calling > grouping_planner. > Also, the adjust_appendrel_attrs_multilevel made it worse for > multi-level partitioning case, because of repeated copying for root to > intermediate partitioned tables, as Imai-san pointed out. > > I've fixed that making sure that query tree is translated only once and > saved for later steps to use. Imai-san, please check the memory > consumption with the latest patch. Thanks for fixing! Now, memory consumption is lower than the previous. with v7 patches, Set1: 223MB with v7 patches, Set2: 226MB Thanks, -- Yoshikazu Imai
pgsql-hackers by date: