Re: 8.4 open item: copy performance regression? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: 8.4 open item: copy performance regression?
Date
Msg-id 1245658851.31430.45.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: 8.4 open item: copy performance regression?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Mon, 2009-06-22 at 10:52 +0300, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> >> I was going to say that since we flush the WAL every 16MB anyway (at 
> >> every XLOG file switch), you shouldn't see any benefit with larger ring 
> >> buffers, since to fill 16MB of data you're not going to write more than 
> >> 16MB WAL.
> > 
> > I'm not convinced that WAL segment boundaries are particularly relevant
> > to this.  The unit of flushing is an 8K page, not a segment.
> 
> We fsync() the old WAL segment every time we switch to a new WAL 
> segment. That's what I meant by "flush".
> 
> If the walwriter is keeping up, it will fsync() the WAL more often, but 
> 16MB is the maximum distance between fsync()s.

Yes, but the fsync is performed by the process that writes the WAL, not
necessarily by the process that inserts the WAL. In perfect balance, an
inserter-of-WAL could insert an infinite amount of WAL and never need to
fsync the WAL. So the question is are we in balance between WALWriter
and COPY?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: 8.4 open item: copy performance regression?
Next
From: David Fetter
Date:
Subject: Re: security checks for largeobjects?