| From: | Andres Freund <andres(at)anarazel(dot)de> | 
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> | 
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> | 
| Subject: | Re: StrategyGetBuffer optimization, take 2 | 
| Date: | 2013-08-05 16:40:37 | 
| Message-ID: | 20130805164037.GC19850@alap2.anarazel.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2013-08-05 10:49:08 -0500, Merlin Moncure wrote:
> optimization 4: remove free list lock (via Jeff Janes).  This is the
> other optimization: one backend will no longer be able to shut down
> buffer allocation
I think splitting off the actual freelist checking into a spinlock makes
quite a bit of sense. And I think a separate one should be used for the
actual search for the clock sweep.
I don't think the unlocked increment of nextVictimBuffer is a good idea
though. nextVictimBuffer jumping over NBuffers under concurrency seems
like a recipe for disaster to me. At the very, very least it will need a
good wad of comments explaining what it means and how you're allowed to
use it. The current way will lead to at least bgwriter accessing a
nonexistant/out of bounds buffer via StrategySyncStart().
Possibly it won't even save that much, it might just increase the
contention on the buffer header spinlock's cacheline.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-08-05 16:41:52 | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) | 
| Previous Message | Bruce Momjian | 2013-08-05 16:18:25 | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |