On Mon, Dec 20, 2004 at 06:23:24PM +1100, Gavin Sherry wrote:
> On Sat, 18 Dec 2004, Bruce Momjian wrote:
> > Agreed. Once concern I have about allowing the lock table to spill to
> > disk is that a large number of FOR UPDATE locks could push out lock
> > entries used by other backends, causing very poor performance.
>
> I think if we allow the lock manager to spill to disk (and I think we do
> need to allow it) then we should also be able to control the amount of
> shared memory allocated. There's little point spilling the lock table to
> disk if we have huge amounts of memory.
This is a interesting idea.
Gavin also mentioned to me we should also control the amount of memory
the shared inval queue uses. Causing all backends to refill the cache
is (I assume) a big performance hit.
Maybe we should expose this via new knobs in postgresql.conf, to ease
implementation, or maybe not, to rid users of configuring it.
As a start, we could have WARNINGs when the lock table is spilled and
when a SInvalReset occurs. So the user can know whether he should
increase memory use for those settings.
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)