Skip site navigation (1) Skip section navigation (2)

Re: foreign key locks, 2nd attempt

From: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks, 2nd attempt
Date: 2012-02-23 13:08:28
Message-ID: 4F463A4C.9000906@xs4all.nl (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2012-02-23 10:18, Simon Riggs wrote:

> However, review of such a large patch should not be simply pass or
> fail. We should be looking back at the original problem and ask
> ourselves whether some subset of the patch could solve a useful subset
> of the problem. For me, that seems quite likely and this is very
> definitely an important patch.
>
> Even if we can't solve some part of the problem we can at least commit
> some useful parts of infrastructure to allow later work to happen more
> smoothly and quickly.
>
> So please let's not focus on the 100%, lets focus on 80/20.

The suggested immutable-column constraint was meant as a potential 
"80/20 workaround."  Definitely not a full solution, helpful to some, 
probably easier to do.  I don't know if an immutable key would actually 
be enough to elide foreign-key locks though.

Simon, I think you had a reason why it couldn't work, but I didn't quite 
get your meaning and didn't want to distract things further at that 
stage.  You wrote that it "doesn't do what KEY LOCKS are designed to 
do"...  any chance you might recall what the problem was?

I don't mean to be pushy about my pet idea, and heaven knows I don't 
have time to implement it, but it'd be good to know whether I should put 
the whole thought to rest.


Jeroen

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-02-23 14:15:45
Subject: Re: foreign key locks, 2nd attempt
Previous:From: Peter GeogheganDate: 2012-02-23 12:37:51
Subject: Re: pg_stat_statements normalization: re-review

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group