Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
On Tue, Dec 5, 2017 at 1:24 PM, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com> wrote: > On Tue, Dec 5, 2017 at 11:04 AM, Rajkumar Raghuwanshi > <rajkumar.raghuwanshi@enterprisedb.com> wrote: >> On Mon, Dec 4, 2017 at 7:34 AM, Ashutosh Bapat >> <ashutosh.bapat@enterprisedb.com> wrote: >>> I agree, the patch looks longer than expected. I think, it's important >>> to have some testcases to test partition-wise join with default >>> partitions. I think we need at least one test for range default >>> partitions, one test for list partitioning, one for multi-level >>> partitioning and one negative testcase with default partition missing >>> from one side of join. >>> >>> May be we could reduce the number of SQL commands and queries in the >>> patch by adding default partition to every table that participates in >>> partition-wise join (leave the tables participating in negative tests >>> aside.). But that's going to increase the size of EXPLAIN outputs and >>> query results. The negative test may simply drop the default partition >>> from one of the tables. >>> >>> For every table being tested, the patch adds two ALTER TABLE commands, >>> one for detaching an existing partition and then attach the same as >>> default partition. Alternative to that is just add a new default >>> partition without detaching and existing partition. But then the >>> default partition needs to populated with some data, which requires 1 >>> INSERT statement at least. That doesn't reduce the size of patch, but >>> increases the output of query and EXPLAIN plan. >>> >>> May be in case of multi-level partitioning test, we don't need to add >>> DEFAULT in every partitioned relation; adding to one of them would be >>> enough. May be add it to the parent, but that too can be avoided. That >>> would reduce the size of patch a bit. >> >> Thanks Ashutosh for suggestions. >> >> I have reduced test cases as suggested. Attaching updated patch. >> > Sorry Attached wrong patch. > > attaching correct patch now. Thanks. Here are some comments +-- test default partition behavior for range +ALTER TABLE prt1 DETACH PARTITION prt1_p3; +ALTER TABLE prt1 ATTACH PARTITION prt1_p3 DEFAULT; +ALTER TABLE prt2 DETACH PARTITION prt2_p3; +ALTER TABLE prt2 ATTACH PARTITION prt2_p3 DEFAULT; I think we need an ANALYZE here in case the statistics gets updated while DETACH and ATTACH is going on. Other testcases also need to be updated with ANALYZE, including the negative one. +-- partition-wise join can not be applied if the only one of joining table have Correction: ... if only one of the joining tables has ... Please add the patch to the next commitfest so that it's not forgotten. I think we can get rid of the multi-level partition-wise testcase as well. Also, since we are re-attaching existing partition tables as default partitions, we don't need to check the output as well; just plan should be enough. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
Commits
-
Add test for partitionwise join involving default partition.
- 4513d3a4be0b 12.0 landed
-
Rewrite the code that applies scan/join targets to paths.
- 11cf92f6e2e1 11.0 cited
-
Fix code related to partitioning schemes for dropped columns.
- cf7ab13bfb45 11.0 landed
-
Copy information from the relcache instead of pointing to it.
- 45866c75507f 11.0 landed
-
Basic partition-wise join functionality.
- f49842d1ee31 11.0 landed
-
Associate partitioning information with each RelOptInfo.
- 9140cf8269b0 11.0 landed
-
Expand partitioned table RTEs level by level, without flattening.
- 0a480502b092 11.0 landed
-
Set partitioned_rels appropriately when UNION ALL is used.
- 448aa36e8b96 10.0 landed
- 1555566d9ee1 11.0 landed
-
Remove dedicated B-tree root-split record types.
- 0c504a80cf2e 11.0 cited
-
Assorted preparatory refactoring for partition-wise join.
- e139f1953f29 11.0 cited
-
Teach adjust_appendrel_attrs(_multilevel) to do multiple translations.
- 480f1f4329f1 11.0 cited
-
Avoid unnecessary single-child Append nodes.
- d57929afc706 11.0 cited
-
Revisit handling of UNION ALL subqueries with non-Var output columns.
- dd4134ea56cb 9.2.0 cited