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
