| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: augmenting MultiXacts to improve foreign keys |
| Date: | 2011-08-10 00:00:32 |
| Message-ID: | 221E6C16-CC0F-460D-9B84-675CD6312DE2@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Aug 9, 2011, at 4:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Like Florian, I'm considerably more concerned about the aspect of
> deciding which columns are "key columns" and whether they changed.
Should we consider trying implement a system that can lock individual columns?
Either way, my main concern is that we're going to end up pessimizing the common case of UPDATE, by making it do extra work to reduce the chances of a lock conflict from an incoming foreign key. Most of the time there won't be an incoming foreign key, or the referring row won't get updated, and that work will be wasted. It would be nice to just lock the row "for some kind of update" and sort out what exactly we locked only if a possible conflict comes along.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-08-10 00:35:38 | Re: Reduced power consumption in autovacuum launcher process |
| Previous Message | Peter Geoghegan | 2011-08-09 23:25:03 | Re: Reduced power consumption in autovacuum launcher process |