Re: Scaling shared buffer eviction - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Scaling shared buffer eviction
Date
Msg-id CA+TgmoYg5ia22=SxheFvuwLOGzq12JBYJ4qPAAAtpMNK4TGH_g@mail.gmail.com
Whole thread Raw
In response to Re: Scaling shared buffer eviction  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Scaling shared buffer eviction
List pgsql-hackers
On Tue, Aug 26, 2014 at 10:53 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Today, while working on updating the patch to improve locking
> I found that as now we are going to have a new process, we need
> a separate latch in StrategyControl to wakeup that process.
> Another point is I think it will be better to protect
> StrategyControl->completePasses with victimbuf_lck rather than
> freelist_lck, as when we are going to update it we will already be
> holding the victimbuf_lck and it doesn't make much sense to release
> the victimbuf_lck and reacquire freelist_lck to update it.

Sounds reasonable.  I think the key thing at this point is to get a
new version of the patch with the background reclaim running in a
different process than the background writer.  I don't see much point
in fine-tuning the locking regimen until that's done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Scaling shared buffer eviction
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench throttling latency limit