| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: foreign key locks, 2nd attempt |
| Date: | 2012-03-07 11:11:06 |
| Message-ID: | CA+U5nMLAr1VoDsmkJFYvFk_GvW-bqVgQnTLzmAyzLFQhZM1W1Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 7, 2012 at 10:18 AM, Gokulakannan Somasundaram
<gokul007(at)gmail(dot)com> wrote:
>>
>> Insert, Update and Delete don't take locks they simply mark the tuples
>> they change with an xid. Anybody else wanting to "wait on the lock"
>> just waits on the xid. We do insert a lock row for each xid, but not
>> one per row changed.
>
> I mean the foreign key checks here. They take a Select for Share Lock right.
> That's what we are trying to optimize here. Or am i missing something? So by
> following the suggested methodology, the foreign key checks won't take any
> locks.
Please explain in detail your idea of how it will work.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gokulakannan Somasundaram | 2012-03-07 11:37:01 | Re: foreign key locks, 2nd attempt |
| Previous Message | Gokulakannan Somasundaram | 2012-03-07 10:18:26 | Re: foreign key locks, 2nd attempt |