Re: v7.1b4 bad performance - Mailing list pgsql-admin

From Tom Lane
Subject Re: v7.1b4 bad performance
Date
Msg-id 3807.982426380@sss.pgh.pa.us
Whole thread Raw
In response to RE: v7.1b4 bad performance  (Michael Ansley <Michael.Ansley@intec-telecom-systems.com>)
Responses Re: v7.1b4 bad performance  (M Carling <m@axispt.com>)
List pgsql-admin
Michael Ansley <Michael.Ansley@intec-telecom-systems.com> writes:
> I would consider this perfectly acceptable.  Official benchmarks can only be
> without the -F switch prior to 7.1, so in raw performance terms (with
> acceptable safety) you have to compare 7.0.2 without -F to 7.1beta4 with -F,
> because those are the fastest configurations with acceptable recovery.

How's that again?  7.1 with -F is just as much at the mercy of a system
crash as previous releases with -F, because it's not fsync'ing the WAL
log.  In either case, -F is only for those who trust their hardware + OS
+ UPS, or perhaps are running development systems and care more for
speed than data recoverability.

> However, I would also expect 7.0.2 -F to be faster than 7.1beta4 -F, because
> 7.1beta4 is doing more (WAL specifically).  Over the same plans, the engine
> is doing more work, so must be slower.

No, because 7.1 is able to batch writes to data files over multiple
transactions, given enough buffer space (larger -B makes more difference
than it used to).  That buys back some or all of the performance lost to
WAL logfile writes.  See Tatsuo's curves, and the similar numbers posted
by myself and Peter Schmidt.  On that one benchmark, at least, 7.1 is
not slower, even with -F.  (Given zero commit_delay, anyway ;-))

            regards, tom lane

pgsql-admin by date:

Previous
From: Michael Ansley
Date:
Subject: RE: v7.1b4 bad performance
Next
From: Michael Ansley
Date:
Subject: RE: v7.1b4 bad performance