Re: foreign key locks, 2nd attempt

Поиск
Список
Период
Сортировка
От Gokulakannan Somasundaram
Тема Re: foreign key locks, 2nd attempt
Дата
Msg-id CAHMh4-YY3AGrPRQ4jqzjB97KtWj7SFg_tztMh7k4yPJtWyDWKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: foreign key locks, 2nd attempt  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: foreign key locks, 2nd attempt
Список pgsql-hackers
I feel sad, that i followed this topic very late. But i still want to put forward my views. 
Have we thought on the lines of how Robert has implemented relation level locks. In short it should go like this

a) The locks for enforcing Referential integrity should be taken only when the rarest of the events( that would cause the integrity failure) occur. That would be the update of the referenced column. Other cases of update, delete and insert should not be required to take locks. In this way, we can reduce a lot of lock traffic.

So if we have a table like employee( empid, empname, ... depid references dept(deptid)) and table dept(depid depname).

Currently we are taking shared locks on referenced rows in dept table, whenever we are updating something in the employee table. This should not happen. Instead any insert / update of referenced column / delete should check for some lock in its PGPROC structure, which will only get created when the depid gets updated / deleted( rare event )

b) But the operation of update of the referenced column will be made more costly. May be it can create something like a predicate lock(used for enforcing serializable) and keep it in all the PG_PROC structures. 

I know this is a abstract idea, but just wanted to know, whether we have thought on those lines.

Thanks,
Gokul.


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: [9.2] Confusion over CacheRegisterSyscacheCallback