Scott Marlowe wrote:
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.
Yeah, I wouldn't worry about accessing it every 15 minutes! I put the
comment there to make it clear that (like pg_locks) selecting from it
*very frequently* could effect performance.
Cheers
Mark
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
