Re: Fix bug of CHECK constraint enforceability recursion - Mailing list pgsql-hackers

From Zsolt Parragi
Subject Re: Fix bug of CHECK constraint enforceability recursion
Date
Msg-id CAN4CZFNjnR-7hPBO=v=9h4CdDogUueYoPqpPvR9k3X5Z9-=+TA@mail.gmail.com
Whole thread
In response to Re: Fix bug of CHECK constraint enforceability recursion  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
The new version looks correct, I don't see any logic problem with it,
however, I do have a performance question:

+                /*
+                 * A parent listed in changing_conids is being changed by the
+                 * same ALTER, but it may not have been updated yet.  For
+                 * regular inheritance, recurse upward to check whether an
+                 * equivalent enforced parent outside the ALTER will make it
+                 * remain enforced.  Partitions cannot have multiple parents,
+                 * so they do not need this check.
+                 */
+                if (!rel->rd_rel->relispartition &&
+                    list_member_oid(changing_conids, parentcon->oid))

Shouldn't the parent lookup use some form of caching? Otherwise we'll
end up reevaluating the same parents multiple times. I'm not sure if
it is needed or not, how much of a performance impact this can have in
a real-world server.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Next
From: Ethan Mertz
Date:
Subject: Re: Skip prefetch for block references that follow a FPW or WILL_INIT of the same block