From: | "Guy Rouillier" <guyr(at)masergy(dot)com> |
---|---|
To: | "PostgreSQL General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Debugging deadlocks |
Date: | 2005-04-01 00:54:31 |
Message-ID: | CC1CF380F4D70844B01D45982E671B2348E79A@mtxexch01.add0.masergy.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Alvaro Herrera wrote:
>
> Now this can't be applied right away because it's easy to run "out of
> memory" (shared memory for the lock table). Say, a delete or update
> that touches 10000 tuples does not work. I'm currently working on a
> proposal to allow the lock table to spill to disk ...
While not always true, in many cases the cardinality of the referenced
(parent) table is small compared to that of the referencing (child)
table. Does locking require a separate lock record for each tuple in
the child table, or just one for each tuple in the parent table with a
reference count? For example, the scenario I started this thread with
had two child tables referencing rows in a common parent table. For a
given parent tuple, a single "prevent write" lock with a reference count
would seem sufficient.
--
Guy Rouillier
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2005-04-01 00:54:32 | Re: your thoughts on a crazy idea please |
Previous Message | Chandra Sekhar Surapaneni | 2005-04-01 00:47:32 | Help with converting hexadecimal to decimal |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-04-01 01:31:14 | Re: Debugging deadlocks |
Previous Message | Jim C. Nasby | 2005-04-01 00:32:40 | Re: Hash vs. HashJoin nodes |