Re: v7.1b4 bad performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: v7.1b4 bad performance
Дата
Msg-id 3807.982426380@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: v7.1b4 bad performance  (Michael Ansley <Michael.Ansley@intec-telecom-systems.com>)
Ответы Re: v7.1b4 bad performance  (M Carling <m@axispt.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Ansley
Дата:
Сообщение: RE: v7.1b4 bad performance
Следующее
От: Michael Ansley
Дата:
Сообщение: RE: v7.1b4 bad performance