From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Mark Rofail <markm(dot)rofail(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers-owner(at)postgresql(dot)org, Erik Rijkers <er(at)xs4all(dot)nl> |
Subject: | Re: GSoC 2017: Foreign Key Arrays |
Date: | 2017-08-08 13:24:30 |
Message-ID: | CAPpHfdsd9cvKzcdHgFaPLtF0MiopyGHCfUb4wVkVrPgg4vNkZA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 8, 2017 at 4:12 PM, Mark Rofail <markm(dot)rofail(at)gmail(dot)com> wrote:
> On Tue, Aug 8, 2017 at 2:25 PM, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
> wrote:
>>
>> Do we already assume that default btree opclass for array element type
>> matches PK opclass when using @>> operator on UPDATE/DELETE of referenced
>> table?
>>
> I believe so, since it's a polymorphic function.
>
>
>> If so, we don't introduce additional restriction here...
>>
> You mean to remove the wrapper query ?
>
I think we should choose the query which would be better planned (and
presumably faster executed). You can make some experiments and then choose
the query.
> GROUP BY would also use default btree/hash opclass for element type. It
>> doesn't differ from DISTINCT from that point.
>>
> Then there's no going around this limitation,
>
That seems like this.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-08-08 13:50:45 | Re: pgbench: Skipping the creating primary keys after initialization |
Previous Message | Mark Rofail | 2017-08-08 13:12:13 | Re: GSoC 2017: Foreign Key Arrays |