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 (<[EMAIL PROTECTED]>) "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." (2nd Commandment for C programmers) ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org