On Sun, Jul 9, 2017 at 7:42 PM, Alexander Korotkov <aekorot...@gmail.com>
wrote:
> We may document that GIN index is required to accelerate RI queries for
> array FKs. And users are encouraged to manually define them.
> It's also possible to define new option when index on referencing
> column(s) would be created automatically. But I think this option should
> work the same way for regular FKs and array FKs.
>
I just thought because GIN index is suited for composite elements, it would
be appropriate for array FKs.
So we should leave it to the user ? I think tht would be fine too.
*What I did *
- now the RI checks utilise the @>(anyarray, anyelement)
- however there's a small problem:
operator does not exist: integer[] @> smallint
I assume that external casting would be required here. But how can I
downcast smallint to integer or interger to numeric automatically ?
*What I plan to do*
- work on the above mentioned buy/limitation
- otherwise, I think this concludes limitation #5
fatal performance issues. If you issue any UPDATE or DELETE against the PK
> table, you get a query like this for checking to see if the RI constraint
> would be violated:
SELECT 1 FROM ONLY fktable x WHERE $1 = ANY (fkcol) FOR SHARE OF x;.
or is there anything remaining ?
Best Regards,
Mark Rofail
