Re: Spread checkpoint sync - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Spread checkpoint sync
Date
Msg-id 1295099721.427.34.camel@ebony
Whole thread Raw
In response to Re: Spread checkpoint sync  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Spread checkpoint sync
List pgsql-hackers
On Sat, 2011-01-15 at 05:47 -0500, Greg Smith wrote:
> Robert Haas wrote: 
> > On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> >   
> > > One of the ideas Simon and I had been considering at one point was adding
> > > some better de-duplication logic to the fsync absorb code, which I'm
> > > reminded by the pattern here might be helpful independently of other
> > > improvements.
> > >     
> > 
> > Hopefully I'm not stepping on any toes here, but I thought this was an
> > awfully good idea and had a chance to take a look at how hard it would
> > be today while en route from point A to point B.  The answer turned
> > out to be "not very", so PFA a patch that seems to work.  I tested it
> > by attaching gdb to the background writer while running pgbench, and
> > it eliminate the backend fsyncs without even breaking a sweat.
> >   
> 
> No toe damage, this is great, I hadn't gotten to coding for this angle
> yet at all.  Suffering from an overload of ideas and (mostly wasted)
> test data, so thanks for exploring this concept and proving it works.

No toe damage either, but are we sure we want the de-duplication logic
and in this place?

I was originally of the opinion that de-duplicating the list would save
time in the bgwriter, but that guess was wrong by about two orders of
magnitude, IIRC. The extra time in the bgwriter wasn't even noticeable.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add support for logging the current role
Next
From: Robert Haas
Date:
Subject: Re: ALTER TYPE 0: Introduction; test cases