GSoC 2017 Proposal

Hello, Mark!

On Mon, Apr 3, 2017 at 7:00 PM, Mark Rofail <markm.rofail@gmail.com> wrote:

Kindly find my proposal attached to this email.

I'd like to ask what do you mean in research item number 3?

3. Making the full-table sequential scan GIN-indexable​ instead seems very

reasonable since GIN is primarily used to search for element values (PK
values) that appear within composite items (FK array).
a. Statistics have shown[7] that GIN indexing an array shows an increase
in performance by ~2256% !
b. Thus the first step (as proposed ) would be to prove that “<@( is
contained by)” can be used in this scope.

What exactly you're going to do in this item? Check that GIN index over
array support given operator, do the performance benchmark or something
else?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Dear Mr Alexander,

I was checking the archives today and to my shock, I did not find my
reply to your previous question which was almost two weeks ago.
I apologise for the inconvenience, I have however replied within an
hour but apparently, it did not go through.

Best Regards,
Mark Moheb

On Thu, Apr 6, 2017 at 4:18 PM, Mark Rofail <markm.rofail@gmail.com> wrote:

Hello Mr Alexander,

From my understanding, the main issue occurs whenever any UPDATE or
DELETE statement is executed on the PK table,
this triggers a referential integrity check on the FK table. In the
previous patches, this was done by performing a sequential scan.

To improve performance I propose that we index the FK column, and in
my point of view the most suitable index would be the GIN index since
it is targeted for composite items.
However, to move forward with this approach, we have to be sure that
the comparison semantics offered by GIN indexes satisfy our needs for
the referential integrity check.

This approach was proposed by Tom Lane:
/messages/by-id/28389.1351094795@sss.pgh.pa.us

I believe this can be accomplished by better understanding the GIN
index implementation in postgreSQL, including its operators.

This is the best to the knowledge I gained during the application
period. I would like to investigate it further and would be delighted
to hear your input regarding the matter,

Best Regards,
Mark Moheb

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers