Re: data on devel code perf dip

Tom Lane wrote:
> Most of the CVS activity in that time period had to with stuff like
> roles and the interval datatype.  It's conceivable that these things
> had some marginal performance cost, but if so I'd have expected it to
> show up as extra CPU effort (more time checking permissions, say).
> This figure:
> 
> > samples  %        app name                 symbol name
> > 164623113 70.5372  kernel-2.6.11.3          .shared_idle
> 
> says pretty clearly that your problem is all I/O wait, and there are
> no other commits that might have increased our tendency to wait for I/O.
> 
> I am sure I will get some pushback if I propose reverting the O_DIRECT
> patch, so could you try to get some more-specific evidence?  Like pull
> the CVS tree from just before and just after this patch and compare
> performance?
> 
> BTW I did check that both runs are using wal_sync_method = fdatasync
> and wal_buffers = 1000, so it's not a problem of those parameters having
> been changed by the patch.

We can supply a patch with just the O_DIRECT for you to test.  The
O_DIRECT patch also had grouped WAL writes, so that might be an issue
too.  Also, O_DIRECT is only used for open_* wal sync methods, so I
don't see how it would affect this, but the grouped WAL writes might.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073