Re: deferred foreign keys

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: deferred foreign keys
Дата
Msg-id 1073333664.8958.36.camel@jester
обсуждение исходный текст
Ответ на Re: deferred foreign keys  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Ответы Re: deferred foreign keys  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Список pgsql-performance
On Mon, 2004-01-05 at 14:48, Stephan Szabo wrote:
> On Mon, 5 Jan 2004, Vivek Khera wrote:
>
> >
> > On Jan 5, 2004, at 1:57 PM, Stephan Szabo wrote:
> >
> > > But, if he's updating the fk table but not the keyed column, it should
> > > no
> > > longer be doing the check and grabbing the locks.  If he's seeing it
> > > grab
> > > the row locks still a full test case would be handy because it'd
> > > probably
> > > mean we missed something.
> > >
> >
> > I'm not *sure* it is taking any locks.  The transactions appear to be
> > running lock step (operating on different parts of the same pair of
> > tables) and I was going to see if deferring the locks made the
> > difference.  It is my feeling now that it will not.  However, if there
> > is a way to detect if locks are being taken, I'll do that.  I'd like to
> > avoid dropping and recreating the foreign keys if I can since it takes
> > up some bit of time on the table with 20+ million rows.
>
> The only way I can think of to see the locks is to do just one of the
> operations and then manually attempting to select for update the
> associated pk row.

When a locker runs into a row lock held by another transaction, the
locker will show a pending lock on the transaction id in pg_locks.



В списке pgsql-performance по дате отправления:

Предыдущее
От: John Siracusa
Дата:
Сообщение: Re: Select max(foo) and select count(*) optimization
Следующее
От: Neil Conway
Дата:
Сообщение: Re: Select max(foo) and select count(*) optimization