Re: [HACKERS] GSoC 2017: Foreign Key Arrays
| От | Mark Rofail |
|---|---|
| Тема | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
| Дата | |
| Msg-id | CAJvoCuvj2mparxOiFjynNsW31gcEmhZFww8_f55+UqfTzsLsPg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] GSoC 2017: Foreign Key Arrays (Mark Rofail <markm.rofail@gmail.com>) |
| Ответы |
Re: [HACKERS] GSoC 2017: Foreign Key Arrays
|
| Список | pgsql-hackers |
I am having trouble rebasing the patch to the current head. I resolved all conflicts, but there are changes to the codebase that I cannot accommodate.
issue 1: `pg_constraint.c:564`
I need to check that `conppeqop` is not null and copy it but I don't know how to check its type since its a char*
issue 2: `matview.c:768`
I need to pass `fkreftype` but I don't have it in the rest of the function
In other news, I am currently working on exhaustive tests for the GIN operator, but some pointers on how to do so would be appreciated.
Regards,
Mark Rofail
issue 1: `pg_constraint.c:564`
I need to check that `conppeqop` is not null and copy it but I don't know how to check its type since its a char*
issue 2: `matview.c:768`
I need to pass `fkreftype` but I don't have it in the rest of the function
In other news, I am currently working on exhaustive tests for the GIN operator, but some pointers on how to do so would be appreciated.
Regards,
Mark Rofail
On Wed, May 16, 2018 at 10:31 AM, Mark Rofail <markm.rofail@gmail.com> wrote:
I was wondering if anyone knows the proper way to write a benchmarking test for the @>> operator. I used the below script in my previous attempt https://gist.github.com/markrofail/174ed370a2f2ac248 00fde2fc27e2d38 The script does the following steps:
1. Generate Table A with 5 rows
2. Generate Table B with n rows such as:
every row of Table B is an array of IDs referencing rows in Table A.
The tests we ran previously had Table B up to 1 million rows and the results can be seen here :
https://www.postgresql.org/message-id/ CAJvoCusMuLnYZUbwTBKt% 2Bp6bB9GwiTqF95OsQFHXixJj3LkxV Q%40mail.gmail.com
How would we change this so it would be more exhaustive and accurate?
Regards,
Mark Rofail
Вложения
В списке pgsql-hackers по дате отправления: