Thanks for the comments.
On Fri, Aug 9, 2019 at 2:44 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> +++ b/src/backend/optimizer/util/plancat.c
> @@ -1267,10 +1267,14 @@ get_relation_constraints(PlannerInfo *root,
> */
> if (include_partition && relation->rd_rel->relispartition)
> {
> ...
> + else
> {
> + /* Nope, fetch from the relcache. */
>
> I seems to me that include_partition is true both and only for
> modern and old-fasheoned partition parents.
> set_relation_partition_info() is currently called only for modern
> partition parents. If we need that at the place above,
> set_relation_partition_info can be called also for old-fashioned
> partition parent, and get_relation_constraints may forget the
> else case in a broad way.
"include_partition" doesn't have anything to do with what kind the
partition parent is. It is true when the input relation that is a
partition is directly mentioned in the query (RELOPT_BASEREL) and
constraint_exclusion is on (inheritance_planner considerations makes
the actual code a bit hard to follow but we'll hopefully simplify that
in the near future). That is also the only case where we need to
consider the partition constraint when doing constraint exclusion.
Regarding how this relates to partition_qual:
* get_relation_constraints() can use it if it's set, which would be
the case if the partition in question is partitioned itself
* It wouldn't be set if the partition in question is a leaf partition,
so it will have to get it directly from the relcache
> + /* Nope, fetch from the relcache. */
> + List *pcqual = RelationGetPartitionQual(relation);
>
> If the comment above is right, This would be duplicate. What we
> should do instaed is only eval_const_expression. And we could
> move it to set_relation_partition_info completely. Consitify must
> be useful in both cases.
As described above, this block of code is not really duplicative in
the sense that when it runs, that would be the first time in a query
to fetch the partition constraint of the relation in question.
Also, note that expression_planner() calls eval_const_expressions(),
so constification happens in both cases. I guess different places
have grown different styles of processing constraint expressions as
the APIs have evolved over time.
Thanks,
Amit