On Thu, Mar 31, 2005 at 06:54:31PM -0600, Guy Rouillier wrote:
> 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?
Just one. (LOCALLOCK, which is private to each backend, stores how many
times we hold a lock.)
I just realized we not only need to be able to spill LOCK struct to
disk, but also PROCLOCK ... am I right?
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
La web junta la gente porque no importa que clase de mutante sexual seas,
tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con
ciervos incendiándose", y el computador dirá "especifique el tipo de ciervo"
In response to
pgsql-hackers by date
|Next:||From: Qingqing Zhou||Date: 2005-04-01 01:50:49|
|Subject: Re: [ADMIN] Excessive growth of pg_attribute and other system tables|
|Previous:||From: Guy Rouillier||Date: 2005-04-01 00:54:31|
|Subject: Re: Debugging deadlocks|
pgsql-general by date
|Next:||From: Joseph Shraibman||Date: 2005-04-01 01:57:17|
|Subject: table permissions|
|Previous:||From: Dann Corbit||Date: 2005-04-01 00:54:32|
|Subject: Re: your thoughts on a crazy idea please|