Re: Constraint merge and not valid status

Hello,

On 2016/07/25 17:18, Kyotaro HORIGUCHI wrote:
>
>  - Remove ccvalid condition from equalTupleDescs() to reduce
>    unnecessary cache invalidation or tuple rebuilding.

The following commit introduced the ccvalid check:

"""
commit c31305de5f5a4880b0ba2f5983025ef0210a3b2a
Author: Noah Misch <noah@leadboat.com>
Date:   Sun Mar 23 02:13:43 2014 -0400

Address ccvalid/ccnoinherit in TupleDesc support functions.

equalTupleDescs() neglected both of these ConstrCheck fields, and
CreateTupleDescCopyConstr() neglected ccnoinherit.  At this time, the
only known behavior defect resulting from these omissions is constraint
exclusion disregarding a CHECK constraint validated by an ALTER TABLE
VALIDATE CONSTRAINT statement issued earlier in the same transaction.
Back-patch to 9.2, where these fields were introduced.
"""

So, apparently RelationClearRelation() does intend to discard a cached
TupleDesc if ccvalid changed in a transaction.  Whereas,
acquire_inherited_sample_rows() does not seem to depend on ccvalid being
equal or not (or any member of TupleConstr for that matter).  So maybe,
instead of simply discarding the check (which does serve a purpose), we
could make equalTupleDescs() parameterized on whether we want TupleConstr
equality check to be performed or not.  RelationClearRelation() can ask
for the check to be performed by passing true for the parameter whereas
acquire_inherited_sample_rows() and other callers can pass false.  Perhaps
something like the attached.

Thanks,
Amit