On Dec 15, 2010, at 2:40 PM, Jeff Janes wrote:
> On Tue, Dec 14, 2010 at 1:42 PM, Jim Nasby 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
On Tue, Dec 14, 2010 at 1:42 PM, Jim Nasby 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 the pa
On Dec 14, 2010, at 11:08 AM, Jeff Janes wrote:
> On Sun, Dec 12, 2010 at 6:48 PM, Jim Nasby 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 benchmarks, so
On Sun, Dec 12, 2010 at 6:48 PM, Jim Nasby wrote:
> On Dec 10, 2010, at 10:49 AM, Tom Lane wrote:
>> Alvaro Herrera 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 st
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 j
On Dec 10, 2010, at 10:49 AM, Tom Lane wrote:
> Alvaro Herrera 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.
Alvaro Herrera 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 majority of the work
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
> 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 number
> >> of buffers
On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
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 the
>> sweep is.
Loc
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 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 b
On Wed, Dec 8, 2010 at 8:49 PM, Tom Lane wrote:
> Jeff Janes 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
>
>
Jeff Janes 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 designed so that BufFreel
13 matches
Mail list logo
