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
|
Список | 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 по дате отправления: