Re: Partition-wise join for join between (declaratively) partitioned tables
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Attachments
- pg_dp_join_patches_v35.tar.gz (application/x-gzip)
On Tue, Oct 3, 2017 at 7:48 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Sep 21, 2017 at 8:21 AM, Ashutosh Bapat > <ashutosh.bapat@enterprisedb.com> wrote: >> Here's set of rebased patches. The patch with extra tests is not for >> committing. All other patches, except the last one, will need to be >> committed together. The last patch may be committed along with other >> patches or as a separate patch. > > In set_append_rel_size, is it necessary to set attr_needed = > bms_copy(rel->attr_needed[index]) rather than just pointing to the > existing value? If so, perhaps the comments should explain the > reasons. I would have thought that the values wouldn't change after > this point, in which case it might not be necessary to copy them. Right. The only places where attr_needed is changed is in remove_rel_from_query() (useless join removal) and add_vars_to_targetlist(). Both of those happen before set_append_rel_size(). Since parent and child join should project same attributes, having them share the Relids set makes more sense. So, changed accordingly and explained the same in comments. Also, changed list_nth() in the following code block to use list_nth_node(). > > Regarding nomenclature and my previous griping about wisdom, I was > wondering about just calling this a "partition join" like you have in > the regression test. So the GUC would be enable_partition_join, you'd > have generate_partition_join_paths(), etc. Basically just delete > "wise" throughout. Partition-wise join is standard term used in literature and in documentation of other popular DBMSes, so partition_wise makes more sense. But I am fine with partition_join as well. Do you want it partition_join or partitionjoin like enable_mergejoin/enable_hashjoin etc.? > > The elog(DEBUG3) in try_partition_wise_join() doesn't follow message > style guidelines and I think should just be removed. It was useful > for development, I'm sure, but it's time for it to go. Done. > > + elog(ERROR, "unrecognized path node type %d", (int) nodeTag(path)); > > I think we should use the same formulation as elsewhere, namely > "unrecognized node type: %d". And likewise probably "unexpected join > type: %d". Changed "unrecognized path node type" to "unrecognized node type". "unrecognized join type: %d" seems to be used everywhere except postgres_fdw. So, used that. Also added a cast to int similar to other places. > > partition_join_extras.sql has a bunch of whitespace damage, although > it doesn't really matter since, as you say, that's not for commit. > Right. I will remove that patch from the patch-set when those tests are no more needed i.e. once we are done with code changes to the patches. Attached the updated patch-set. -- 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