Re: speeding up planning with partitions
От | Amit Langote |
---|---|
Тема | Re: speeding up planning with partitions |
Дата | |
Msg-id | 9a47429b-5dd7-ace4-e805-835df959355d@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | RE: speeding up planning with partitions ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>) |
Список | pgsql-hackers |
On 2018/11/15 10:19, Imai, Yoshikazu wrote: > On Tue, Nov 13, 2018 at 10:29 PM, Amit Langote wrote: >> On 2018/11/12 13:35, Imai, Yoshikazu wrote: >>> 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 >> >> 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 for checking. So at least we no longer have any memory over-allocation bug with the patch, but perhaps other bugs are still lurking. :) Regards, Amit
В списке pgsql-hackers по дате отправления: