Forgot to mention a couple of important points about the relation of some of the patches here to the patches and discussion at the partitionwise-join thread [1].
On 2017/09/06 19:38, Amit Langote wrote: > [PATCH 1/5] Expand partitioned inheritance in a non-flattened manner > > This will allow us to perform scan and join planning in a per partition > sub-tree manner, with each sub-tree's root getting its own RelOptInfo. > Previously, only the root of the whole partition tree would get a > RelOptInfo, along with the leaf partitions, with each leaf partition's > AppendRelInfo pointing to the former as its parent. > > This is essential, because we will be doing partition-pruning for every > partitioned table in the tree by matching query's scan keys with its > partition key. We won't be able to do that if the intermediate > partitioned tables didn't have a RelOptInfo. There is a patch in the Ashutosh's posted series of patches, which does more or less the same thing that this patch does. He included it in his series of patches, because, IIUC, the main partitionwise-join planning logic that one of the later patch implements depends on being able to consider applying that new planning technique individually for every partition sub-tree, instead of just at the whole tree root. One notable difference from his patch is that while his patch will expand in non-flattened manner even in the case where the parent is the result relation of a query, my patch doesn't in that case, because the new partition-pruning technique cannot be applied to inheritance parent that is a result relation, for example, update partitioned_table set ... And AFAICS, partitionwise-join cannot be applied to such a parent either. Note however that if there are other instances of the same partitioned table (in the FROM list of an update statement) or other partitioned tables in the query, they will be expanded in a non-flattened manner, because they are themselves not the result relations of the query. So, the new partition-pruning and (supposedly) partitionwise-join can be applied for those other partitioned tables. > [PATCH 2/5] WIP: planner-side changes for partition-pruni[...] > > Also, it adds certain fields to RelOptInfos of the partitioned tables that > reflect its partitioning properties. There is something called PartitionScheme, which is a notion one of the Ashutosh's patches invented that this patch incorporates as one of the new fields in RelOptInfo that I mentioned above (also a list of PartitionScheme's in the planner-global PlannerInfo). Although, PartitionScheme is not significant for the task of partition-pruning itself, it's still useful. On Ashutosh's suggestion, I adopted the same in my patch series, so that the partition-wise join patch doesn't end up conflicting with the partition-pruning patch while trying to implement the same and can get straight to the task of implementing partition-wise joins. The same patch in the partition-wise join patch series that introduces PartitionScheme, also introduces a field in the RelOptInfo called partexprs, which records the partition key expressions. Since, partition-pruning has use for the same, I incorporated the same here; also, in a format that Ashutosh's partition-wise patch can use directly, instead of the latter having to hack it again to make it suitable to store partition key expressions of joinrels. Again, that's to minimize conflicts and let his patch just find the field to use as is, instead of implementing it first. Lastly, this patch introduces a PartitionAppendInfo in a partitioned table's RelOptInfo that stores AppendRelInfos of the partitions (child relations) that survive partition-pruning, which serves to identify those partitions' RelOptInfos. Along with the identities of surviving partitions, it also stores the partitioning configuration of the partitioned table after partitions are pruned. That includes partdesc->boundinfo (which is simply a pointer into the table's relcache) and a few other fields that are set by partition-pruning code, such min_datum_index, max_datum_index, null_partition_chosen, that describe the result after pruning. So, for two partitioned tables being joined, if the boundinfos match per partition_bounds_equal() and these other fields match, they can be safely partition-wise joined. [1] https://www.postgresql.org/message-id/CAFjFpRfRDhWp%3DoguNjyzN%3DNMoOD%2BRCC3wS%2Bb%2BxbGKwKUk0dRKg%40mail.gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
