On Tue, Dec 14, 2010 at 1:42 PM, Jim Nasby j...@nasby.net wrote:
On Dec 14, 2010, at 11:08 AM, Jeff Janes wrote:
I wouldn't expect an increase in shared_buffers to make contention on
BufFreelistLock worse. If the increased buffers are used to hold
heavily-accessed data, then you will find
On Dec 15, 2010, at 2:40 PM, Jeff Janes wrote:
On Tue, Dec 14, 2010 at 1:42 PM, Jim Nasby j...@nasby.net wrote:
On Dec 14, 2010, at 11:08 AM, Jeff Janes wrote:
I wouldn't expect an increase in shared_buffers to make contention on
BufFreelistLock worse. If the increased buffers are used to
On Sun, Dec 12, 2010 at 6:48 PM, Jim Nasby j...@nasby.net wrote:
On Dec 10, 2010, at 10:49 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
As far as I can tell, bgwriter never adds things to the
On Dec 14, 2010, at 11:08 AM, Jeff Janes wrote:
On Sun, Dec 12, 2010 at 6:48 PM, Jim Nasby j...@nasby.net wrote:
BTW, when we moved from 96G to 192G servers I tried increasing shared
buffers from 8G to 28G and performance went down enough to be noticeable (we
don't have any good
On Dec 12, 2010, at 8:48 PM, Jim Nasby wrote:
There might be some advantage in having it move buffers
to a freelist that's just protected by a simple spinlock (or at least,
a lock different from the one that protects the clock sweep). The
idea would be that most of the time, backends just
On Dec 10, 2010, at 10:49 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
As far as I can tell, bgwriter never adds things to the freelist.
That is only done at start up, and when a relation or a
Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
Ideally, the clock sweep would be run by bgwriter and not individual
backends. In that case it shouldn't matter much what the performance of the
sweep is. To do that I think we'd want the bgwriter to target there being X
On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
Ideally, the clock sweep would be run by bgwriter and not individual
backends. In that case it shouldn't matter much what the performance of
Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
To do that I think we'd want the bgwriter to target there being X
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
As far as I can tell, bgwriter never adds things to the freelist.
That is only done at start up, and when a relation or a database is
dropped. The clock sweep does the vast
On Dec 8, 2010, at 11:44 PM, Jeff Janes wrote:
For the clock sweep algorithm, I think you could access
nextVictimBuffer without any type of locking.
This is wrong, mainly because you wouldn't have any security against two
processes decrementing the usage count of the same buffer because
I think that the BufFreelistLock can be a contention bottleneck on a
system with a lot of CPUs that do a lot of shared-buffer allocations
which can fulfilled by the OS buffer cache. That is, read-mostly
queries where the working data set fits in RAM, but not in
shared_buffers. (You can always
Jeff Janes jeff.ja...@gmail.com writes:
I think that the BufFreelistLock can be a contention bottleneck on a
system with a lot of CPUs that do a lot of shared-buffer allocations
which can fulfilled by the OS buffer cache.
Really? buffer/README says
The buffer
management policy is
On Wed, Dec 8, 2010 at 8:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
I think that the BufFreelistLock can be a contention bottleneck on a
system with a lot of CPUs that do a lot of shared-buffer allocations
which can fulfilled by the OS buffer cache.
14 matches
Mail list logo
