From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(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 01:12:59 |
Message-ID: | 20130609011259.GB445736@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 08, 2013 at 08:20:42PM -0400, Robert Haas wrote:
> On Sat, Jun 8, 2013 at 5:41 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > 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?
The action discussed so far is RI_FKey_check_ins(). It acquires a KEY SHARE
lock (idempotent by nature) on a row that it finds using B-tree equality
(presumed IMMUTABLE, thus idempotent). RI_FKey_check_upd() is nearly the same
action, so the same argument holds. Before treating any other operation in
the same way, one would need to conduct similar analysis.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2013-06-09 02:00:58 | Re: Cost limited statements RFC |
Previous Message | Robert Haas | 2013-06-09 00:37:21 | Re: Cost limited statements RFC |