Re: data on devel code perf dip

I wrote:
> I've been sniffing around that patch and not really finding any smoking
> gun about why it would make things slower when you're not using O_DIRECT.

While rewriting the patch to fit more naturally into xlog.c, I found a
bug that might possibly be related to your performance issue.  The
if-test in this fragment is wrong:
       /*        * If we just wrote the whole last page of a logfile segment,        * fsync the segment immediately.
Thisavoids having to go back        * and re-open prior segments when an fsync request comes along        * later.
Doingit here ensures that one and only one backend will        * perform this fsync.        *        * This is also the
rightplace to notify the Archiver that the        * segment is ready to copy to archival storage.        */       if
(openLogOff+ pages.size >= XLogSegSize && !ispartialpage)       {           XLogPageFlush(&pages, currentIndex);
  issue_xlog_fsync();           ...
 

Because of the patch's logic changes, openLogOff is not the right thing
to be examining here --- we have not yet done a seek to ensure that it
matches the write start point.  (pages.offset + pages.size would have
worked instead.)

The implication of this is that the code might either fail to do a write
and fsync when it needs to, or do extra fsyncs that it doesn't need to
do.  I am wondering if the latter could explain your issue.  Right
offhand it doesn't seem like this would lead to enough extra fsyncs
to account for the amount of slowdown you report --- but there just
doesn't seem to be anything else in there that could account for it.

I've committed a patch that fixes this and makes some other minor
improvements (which you probably won't notice given that you're using
such a large wal_buffers setting).  You might like to update to CVS
tip (make sure you get xlog.c 1.218 or later) and see if things are
any better or not.
        regards, tom lane