Re: foreign key constraint lock behavour in postgresql

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Robert Haas *EXTERN*" <robertmhaas(at)gmail(dot)com>
Cc: <david(at)lang(dot)hm>, "wangyuxiang" <wyx6fox(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: foreign key constraint lock behavour in postgresql
Date: 2010-02-09 15:22:50
Message-ID: D960CB61B694CF459DCFB4B0128514C20393815D@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I wrote:
> > One idea that occurs to me is that it might be possible to add to PG
> > some tuple lock modes that are intended to cover updates that don't
> > touch indexed columns. So, say:
> >
> > SHARED NONINDEX - conflicts only with EXCLUSIVE locks
> > SHARED - conflicts with EXCLUSIVE or EXCLUSIVE NONINDEX locks
> > EXCLUSIVE NONINDEX - conflicts with any lock except SHARED NONINDEX.
> > must have this level or higher to update tuple.
> > EXCLUSIVE - conflicts with any other lock. must have this to update
> > any indexed column of a tuple.
> >
> > Then a foreign key constraint could take a SHARED NONINDEX lock on the
> > target tuple, because any column that's the target of a foreign key
> > must be indexed; and so we don't care if the nonindexed columns get
> > updated under us. I think. Also, I believe you'd also need to
> > duplicate any SHARED NONINDEX locks for any new versions of the tuple
> > that got created while the lock was held, which might be sticky.
>
> That should work and improve concurrency in PostgreSQL!

Even more if EXCLUSIVE NONINDEX is also used for updates that
change indexed columns where the index is not UNIQUE.

Yours,
Laurenz Albe

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2010-02-09 16:14:38 moving pg_xlog -- yeah, it's worth it!
Previous Message Scott Marlowe 2010-02-09 09:43:58 Re: index is not using