Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Поиск
Список
Период
Сортировка
От Mark Rofail
Тема Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Дата
Msg-id CAJvoCusw_s_ofSUmOL99KRiOBdUbGOxbBAco6PcH-b=YD8ep+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Mark Rofail <markm.rofail@gmail.com>)
Ответы Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Andreas Karlsson <andreas@proxel.se>)
Список pgsql-hackers
Дерево обсуждения
As pointed out by the CI, created by Thomas Munro, the btree_gin regression tests fail when running "make check-world"
https://travis-ci.org/postgresql-cfbot/postgresql/builds/274732512

The full backtrace can be found here: https://pastebin.com/5q3SG8kV.

The error originates from src/backend/access/gin/ginscan.c:182, where the following if condition if (strategy == 5 && nQueryValues == 1) returns false postivies .

The if condition is necessary since it decides whether  "the queryKey" variable is a single element or the first cell of an array. The logic behind the if condition is as follows: since we defined GinContainsElemStrategy to be strategy number 5. are sure the strategy is GinContainsElemStrategy.
The if condition needs to be more precise but can't find a common attribute to check within the ginFillScanKey() function.

If someone can take a look. I can use some help with this.


I also worked in another direction. Since there was a lot of modifications in the code to support taking an element instead of an array and this is the source of many conflicts. I tried going back to the old RI query:  
SELECT 1 FROM ONLY fktable x WHERE ARRAY[$1] <@ fkcol FOR SHARE OF x;

instead of
SELECT 1 FROM ONLY fktable x WHERE $1 @> fkcol FOR SHARE OF x;

We were worried about the decrease in performance caused by creating a new array with every check So I put it to the test and here are the results: https://pastebin.com/carj9Bur
note: v5 is with SELECT 1 FROM ONLY fktable x WHERE $1 @> fkcol FOR SHARE OF x;
and v5.1 is with SELECT 1 FROM ONLY fktable x WHERE ARRAY[$1] <@ fkcol FOR SHARE OF x;

As expected it led to a decrease in performance, but I think it is forgivable.
Now all the contrib regression tests pass.

To summarise, we can fix the old if condition or neglect the decrease in performance encountered when going back to the old RI query.

Best Regards,
Mark Rofail
Вложения

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] expanding inheritance in partition bound order