Re: GSoC 2017: Foreign Key Arrays

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

In response to

Responses

Browse pgsql-hackers by date

  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