Re: Huge memory consumption on partitioned table with FKs

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