RE: speeding up planning with partitions
От | Imai, Yoshikazu |
---|---|
Тема | RE: speeding up planning with partitions |
Дата | |
Msg-id | 0F97FA9ABBDBE54F91744A9B37151A51293422@g01jpexmbkw24 обсуждение исходный текст |
Ответ на | Re: speeding up planning with partitions (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: speeding up planning with partitions
|
Список | pgsql-hackers |
Hi Amit-san. On Fri, Feb 22, 2019 at 5:55 PM, Amit Langote wrote: > > Please find attached updated patches. I've made a few updates in last > couple of hours such as improving comments, fixing a few thinkos in > inheritance_planner changes, etc. Thanks for the patch. While doing code review of v24-0001, I found the performance degradation case. [creating tables] drop table rt; create table rt (a int, b int, c int) partition by range (a); \o /dev/null select 'create table rt' || x::text || ' partition of rt for values from (' || (x)::text || ') to (' || (x+1)::text || ');' from generate_series(1, 3) x; \gexec \o drop table if exists jrt; create table jrt (a int, b int, c int) partition by range (a); \o /dev/null select 'create table jrt' || x::text || ' partition of jrt for values from (' || (x)::text || ') to (' || (x+1)::text || ');' from generate_series(1, 1024) x; \gexec \o [update_pt_with_joining_another_pt.sql] update rt set c = jrt.c + 100 from jrt where rt.b = jrt.b; [pgbench] pgbench -n -f update_pt_with_joining_another_pt_for_ptkey.sql -T 60 postgres [results] (part_num_rt, part_num_jrt) master patched(0001) --------------------------- ------ ------------- (3, 1024) 8.06 5.89 (3, 2048) 1.52 0.87 (6, 1024) 4.11 1.77 With HEAD, we add target inheritance and source inheritance to parse->rtable in inheritance_planner and copy and adjust itfor child tables at beginning of each planning of child tables. With the 0001 patch, we add target inheritance to parse->rtable in inheritance_planner and add source inheritance to parse->rtablein make_one_rel(under grouping_planner()) during each planning of child tables. Adding source inheritance to parse->rtable may be the same process between each planning of child tables and it might beuseless. OTOH, from the POV of making inheritance-expansion-at-bottom better, expanding source inheritance in make_one_relseems correct design to me. How should we do that...? -- Yoshikazu Imai
В списке pgsql-hackers по дате отправления: