RE: speeding up planning with partitions - Mailing list pgsql-hackers

From Imai, Yoshikazu
Subject RE: speeding up planning with partitions
Date
Msg-id 0F97FA9ABBDBE54F91744A9B37151A51293422@g01jpexmbkw24
Whole thread Raw
In response to Re: speeding up planning with partitions  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: speeding up planning with partitions
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Should we increase the default vacuum_cost_limit?
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Protect syscache from bloating with negative cache entries