Hi, Amit Thanks for the quick modification.
On Wed, Dec 5, 2018 at 8:26 PM, Amit Langote wrote: > > 1. ... > > 5. > > 0003: line 1620-1621 > > > > + * After creating the RelOptInfo for the given child RT index, it goes on > > to > > + * initialize some of its fields base on the parent RelOptInfo. > > > > s/fields base on/fields based on/ > > Fixed all of 1-5. Thanks for fixing. > > 6. > > parsenodes.h > > 906 * inh is true for relation references that should be expanded to > > include > > 907 * inheritance children, if the rel has any. This *must* be false > > for > > 908 * RTEs other than RTE_RELATION entries. > > > > I think inh can become true now even if RTEKind equals RTE_SUBQUERY, so > > latter > > sentence need to be modified. > > > > Seems like an existing comment bug. Why don't you send a patch as you > discovered it? :) Thanks, I am pleased with your proposal. I'll post it as a small fix of the comment. > > 7. > > 0005: line 109-115 ... > Un-pruned partitions may become dummy due to contradictory constraints or > constraint exclusion using normal CHECK constraints later and whether it's > dummy is checked properly by functions that iterate over live_parts. Ah, I understand partitions are eliminated contradictory constraints or constraint exclusion, both using constraints. > Attached updated patches. I have a few other changes in mind to make to > 0001 such that the range table in each child's version of Query contains > only that child table in place of the original target relation, instead of > *all* child tables which is the current behavior. The current behavior > makes range_table_mutator a big bottleneck when the number of un-pruned > target children is large. But I'm saving it for the next week so that I OK. I will continue the review of 0001 before/after your supplying of next patch with keeping those in mind. > can prepare for the PGConf.ASIA that's starting on Monday next week. See > you there. :) Yeah, see you there. :) -- Yoshikazu Imai
