From: | Mark Rofail <markm(dot)rofail(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: GSoC 2017: Foreign Key Arrays |
Date: | 2017-07-22 21:50:53 |
Message-ID: | CAJvoCutDxVvxD+3nx=m3z3++arzEfcrjV59YLkgBVfMMHU=hWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Okay, so I'm trying to test the performance of Foreign Key Array for 3
scenarios: Original Patch, After My Modifications and After My
Modifications with GIN index on the referencing column.
I have attached the sql test file here. It contains about 10k row
insertions.
However, there is a bug that prevented me from testing the third scenario,
I assume there's an issue of incompatible types problem since the right
operand type is anyelement and the supporting procedures expect anyarray.
I am working on debugging it right now.
But if it comes to it, should I introduce a new opclass specifically for
anyelement or add new supporting procedures to the old opclass ? .
I have also attached the results for the first 2 scenarios, however, the
third scenario is the most important one since it's what the project is all
about.
Also, this is kind of interesting. Upon reviewing the results
SELECT 1 FROM ONLY fktable x WHERE $1 @> fkcol FOR SHARE OF x;
produces worse results than the original
SELECT 1 FROM ONLY fktable x WHERE $1 = ANY (fkcol) FOR SHARE OF x;
so personally I don't think we should leave creating a GIN index up to the
user, it should be automatically generated instead.
Attachment | Content-Type | Size |
---|---|---|
element_foreign_key_performance.sql | application/sql | 627.8 KB |
original_patch_results.out | application/octet-stream | 643.1 KB |
modified_results.out | application/octet-stream | 643.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-07-23 02:32:00 | Re: Syncing sql extension versions with shared library versions |
Previous Message | Tom Lane | 2017-07-22 20:32:39 | Re: Buildfarm failure and dubious coding in predicate.c |