RE: speeding up planning with partitions

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