Josh Berkus <[EMAIL PROTECTED]> writes:
> Here's a top-level summary:

> shared_buffers        % RAM           NOTPM20*
> 1000                  0.2%            1287
> 23000                 5%              1507
> 46000                 10%             1481
> 69000                 15%             1382
> 92000                 20%             1375
> 115000                25%             1380
> 138000                30%             1344

> As you can see, the "sweet spot" appears to be between 5% and 10% of RAM, 
> which is if anything *lower* than recommendations for 7.4!   

This doesn't actually surprise me a lot.  There are a number of aspects
of Postgres that will get slower the more buffers there are.

One thing that I hadn't focused on till just now, which is a new
overhead in 8.0, is that StrategyDirtyBufferList() scans the *entire*
buffer list *every time it's called*, which is to say once per bgwriter
loop.  And to add insult to injury, it's doing that with the BufMgrLock
held (not that it's got any choice).

We could alleviate this by changing the API between this function and
BufferSync, such that StrategyDirtyBufferList can stop as soon as it's
found all the buffers that are going to be written in this bgwriter
cycle ... but AFAICS that means abandoning the "bgwriter_percent" knob
since you'd never really know how many dirty pages there were

BTW, what is the actual size of the test database (disk footprint wise)
and how much of that do you think is heavily accessed during the run?
It's possible that the test conditions are such that adjusting
shared_buffers isn't going to mean anything anyway.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to