At Mon, 30 Nov 2020 21:03:45 -0300, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in
> On 2020-Nov-26, Kyotaro Horiguchi wrote:
>
> > This shares RI_ConstraintInfo cache by constraints that shares the
> > same parent constraints. But you forgot that the cache contains some
> > members that can differ among partitions.
> >
> > Consider the case of attaching a partition that have experienced a
> > column deletion.
>
> I think this can be solved easily in the patch, by having
> ri_BuildQueryKey() compare the parent's fk_attnums to the parent; if
> they are equal then use the parent's constaint_id, otherwise use the
> child constraint. That way, the cache entry is reused in the common
> case where they are identical.
*I* think it's the direction. After an off-list discussion, we
confirmed that even in that case the patch works as is because
fk_attnum (or contuple.conkey) always stores key attnums compatible
to the topmost parent when conparent has a valid value (assuming the
current usage of fk_attnum), but I still feel uneasy to rely on that
unclear behavior.
> I would embed all this knowledge in ri_BuildQueryKey though, without
> adding the new function ri_GetParentConstOid. I don't think that
> function meaningful abstraction value, and instead it would make what I
> suggest more difficult.
It seems to me reasonable.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center