Jim Nasby <j...@nasby.net> Thursday 24 March 2011 20:36:48 > On Mar 23, 2011, at 5:12 PM, Tom Lane wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> It looks like the only way anything can ever get put on the free list > >> right now is if a relation or database is dropped. That doesn't seem > >> too good. > > > > Why not? AIUI the free list is only for buffers that are totally dead, > > ie contain no info that's possibly of interest to anybody. It is *not* > > meant to substitute for running the clock sweep when you have to discard > > a live buffer. > > Turns out we've had this discussion before: > http://archives.postgresql.org/pgsql-hackers/2010-12/msg01088.php and > http://archives.postgresql.org/pgsql-hackers/2010-12/msg00689.php > > Tom made the point in the first one that it might be good to proactively > move buffers to the freelist so that backends would normally just have to > hit the freelist and not run the sweep. > > Unfortunately I haven't yet been able to do any performance testing of any > of this... perhaps someone else can try and measure the amount of time > spent by backends running the clock sweep with different shared buffer > sizes. -- > Jim C. Nasby, Database Architect j...@nasby.net > 512.569.9461 (cell) http://jim.nasby.net
Will not be enough to take spin lock (or make ASM (lock) and increment call for Intels/AMD) around increment StrategyControl->nextVictimBuffer, everything here may be controlled by macro GetNextVictimBuffer(). Within for (;;) the valid buffer may be obtained with modulo NBuffers, to decrease lock time. We may try to calculate how many buffers we had skipped, and decrease e.g. trycount by this value, and put some additional restriction like no more passes then NBuffers*4 calls, and notify error. This will made clock sweep concurrent. Regards, Radek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
