Thomas Kellerer wrote:
>>
>> http://suckit.blog.hu/2009/09/29/postgresql_history
>>
>
> It would be interesting to know why the max. performance in the r/w
> scenario for 8.4.1 is lower compared to 8.3.7 (and if maybe 8.4.2
> fixed this)
Based on tests showing a similar style and magnitude regression at Sun
by Jignesh Shah, I would assume this is mainly because some of the
starting parameter changes in 8.4 detuned this particular benchmark a
bit, in favor of proving a better default for real-world users. For
example, the starting default_statistics_target was raised from 10 to
100 in 8.4. This causes a mild decrease in performance on trivial
benchmarks like this one, while potentially providing a large
improvement in the sorts of query plans seen in real applications.
That was the basic theme for the sorts of performance changes that
showed up in 8.4. Another example (not actually relevant to this
benchmark) is that the Free Space Map used to track deleted items is now
kept on disk instead of in shared memory. That's obviously less
efficient in the short term--disk write instead of just a memory
one--but it prevents all sorts of nasty worst-case scenarios you used to
run into the FSM wasn't big enough in earlier versions. Basically, the
8.4 performance related changes reduced average performance on trivial
benchmark workloads a small amount, in favor of large improvements in
the sort of situations people run into in production deployments. I
think it was the right trade-off to make.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us