Hi, On 2019/03/28 7:29, David Rowley wrote: > On Wed, 27 Mar 2019 at 19:48, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Sorry if this was discussed before, but why does this patch add any new >> code to partprune.c? AFAICT, there's no functionality changes to the >> pruning code. > > You're right. It probably shouldn't be there. There's a bit of a lack > of a good home for partition code relating to the planner it seems.
partprune.c is outside the optimizer sub-directory, but exports planning-related functions like prune_append_rel_partitions(), make_partition_pruneinfo(), etc. Similarly, partbound.c can grow bit of planning-related functionality. >> Regarding >> >> +bool >> +partitions_are_ordered(PlannerInfo *root, RelOptInfo *partrel) >> >> I think this could simply be: >> >> bool >> partitions_are_ordered(PartitionBoundInfo *boundinfo) >> >> and be defined in partitioning/partbounds.c. If you think any future >> modifications to this will require access to the partition key info in >> PartitionScheme, maybe the following is fine: >> >> bool >> partitions_are_ordered(RelOptInfo *partrel) > > It does need to know how many partitions the partitioned table has, > which it gets from partrel->nparts, so yeah, RelOptInfo is probably > needed. I don't think passing in int nparts is a good solution to > that. The problem with moving it to partbounds.c is that nothing > there knows about RelOptInfo currently. Maybe, this could be a start. Also, there is a patch in nearby thread which adds additional functionality to partbounds.c to be used by partitionwise join code in the optimizer [1]. Thanks, Amit [1] https://commitfest.postgresql.org/22/1553/
