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.
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2012-02-23 14:15:45|
|Subject: Re: foreign key locks, 2nd attempt|
|Previous:||From: Peter Geoghegan||Date: 2012-02-23 12:37:51|
|Subject: Re: pg_stat_statements normalization: re-review|