My proposal is to target the performance issue regarding the foreign keys for the array index. Any UPDATE or DELETE statement on a Primary Key table would trigger an IR constraint violation check on the Foreign Key table which can only be accomplished by a sequential search. This renders the feature unusable for large tables. I plan to make the array GIN-indexable. Since GIN-Indexes seem very reasonable since GIN is primarily used to search for element values (PK values) that appear within composite items (FK array). This would greatly decrease the computation time since we can utilize the GIN class operator “<@” (included in). I found some statistics that support the GIN vs. Sequential scan, they are included in the proposal.