Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Поиск
Список
Период
Сортировка
От Mark Rofail
Тема Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Дата
Msg-id CAJvoCuso0avp5Wu6v4wFFQXu3sdD+1buzA1Dh2RHJ8k_yZHr3A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Список pgsql-hackers
Дерево обсуждения
On Sun, Jul 9, 2017 at 7:42 PM, Alexander Korotkov <aekorotkov@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 

В списке pgsql-hackers по дате отправления: