On Mon, Nov 24, 2008 at 12:52 PM, Brad Nicholson <bnichols@xxxxxxxxxxxxxxx> wrote: >> I just ran it in a loop over and over on my 8 core opteron server and >> it ran the load factor up by almost exactly 1.0. Under our normal >> daily load, it sits at 1.9 to 2.5, and it climbed to 2.9 under the new >> load of running that query over and over. So, it doesn't seem to be >> blocking or anything. > > The internal docs for pg_buffercache_pages.c state: > > "To get a consistent picture of the buffer state, we must lock all > partitions of the buffer map. Needless to say, this is horrible > for concurrency. Must grab locks in increasing order to avoid > possible deadlocks." Well, the pg hackers tend to take a parnoid view (it's a good thing TM) on things like this. My guess is that the period of time for which pg_buffercache takes locks on the buffer map are short enough that it isn't a real big deal on a fast enough server. On mine, it certainly had no real negative effects for the 5 minutes or so it was running in a loop. None I could see, and we run hundreds of queries per second on our system. Of course, for certain other types of loads it could be a much bigger issue. But for our load, on our machine, it was virtually unnoticeable. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
