Re: CommitDelay performance improvement

ncm(at)zembu(dot)com (Nathan Myers) writes:
> At low loads, it seems (100k,1) (brown +) did best by far, which seems
> very odd. Even more odd, it did pretty well at very high loads but had
> problems at intermediate loads.

In theory, all these variants should behave exactly the same for a
single client, since there will be no commit delay in any of 'em in
that case. I'm inclined to write off the aberrant result for 100k/1
as due to outside factors --- maybe the WAL file happened to be located
in a particularly convenient place on the disk during that run, or
some such. Since there's only 100 transactions in that test, it wouldn't
take much to affect the result.

Likewise, the places where one mid-load datapoint is well below either
neighbor are probably due to outside factors --- either a background
WAL checkpoint or other activity on the machine, mail arrival for
instance. I left the machine alone during the test, but I didn't bother
to shut down the usual system services.

My feeling is that this test run tells us that zero commit delay is
inferior to nonzero under these test conditions, but there's too much
noise to pick out one of the nonzero-delay parameter combinations as
being clearly better than the rest. (BTW, I did repeat the zero-delay
series just to be sure it wasn't itself an outlier...)

regards, tom lane