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. > seem like their logic is specialized enough to be confined to pathkeys.c, > only because it's needed there. Yeah maybe. > 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. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services