Re: [HACKERS] GSoC 2017: Foreign Key Arrays - Mailing list pgsql-hackers

From Mark Rofail
Subject Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Date
Msg-id CAJvoCusMuLnYZUbwTBKt+p6bB9GwiTqF95OsQFHXixJj3LkxVQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Mark Rofail <markm.rofail@gmail.com>)
Responses Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Mark Rofail <markm.rofail@gmail.com>)
List pgsql-hackers
Okay... There are several developments...

1) Whenever there was an index on the Foreign Key Array column and I issue the following query "SELECT * FROM FKTABLEFORARRAY WHERE ftest1 @>> 5;" I wouldn't get any results, even though it works without an index.
This confirmed my suspicion that there was something wrong with the GIN index, the results were too good to be true in the comparison here. It's almost O(1);

Turns out the index search wasn't performed at all. When I fixed this bug, the performance changed. And the new benchmark graph is attached below.

2) About coercion, coercion should only be allowed one way not the other. Since casting the FK column defeats the index and performance drops drastically. I don't want to disallow it though. Should I leave it up to the user?

3) As of patch v4.4 DELETE CASCADE is now supported. The rest of the actions, however, will require array manipulation.

Once the updates are confirmed, I'll update the limitation checklist.

Best Regards,
Mark Rofail
Attachment

pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: [HACKERS] [PROPOSAL] Text search configuration extension
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] shm_mq_wait_internal gets stuck forever on fast shutdown