From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimising Foreign Key checks |
Date: | 2013-06-09 00:20:42 |
Message-ID: | CA+TgmobwWxrnP2-AfLv9pXsRr0ye=mWdT6cw-a_6rphORFvKZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 8, 2013 at 5:41 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> This does appear to specify FK timing semantics like PostgreSQL gives today.
> Namely, it does not permit a FK-induced error when later actions of the query
> that prompted the check could possibly remedy the violation.
Yeah. Standard or no standard, I think we'd have unhappy users if we
broke that.
>> I can't see anything there that stops me applying locks as we go, but
Not sure I follow that bit but...
> Likewise; I don't see why we couldn't perform an optimistic check ASAP and
> schedule a final after-statement check when an early check fails. That
> changes performance characteristics without changing semantics.
...this seems like it might have some promise; but what if the action
we're performing isn't idempotent? And how do we know?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | MauMau | 2013-06-09 00:32:25 | Re: Hard limit on WAL space used (because PANIC sucks) |
Previous Message | Robert Haas | 2013-06-09 00:09:15 | Re: [COMMITTERS] pgsql: Don't downcase non-ascii identifier chars in multi-byte encoding |