Обсуждение: Performance comparison

Hoi,

I remember a while back someone posted a graphs showing a scalability
of postgresql for various versions (I think 8.0 to 8.4). I've tried to
find this image again but havn't been able to locate it. Does anyone
here remember?

Mvg,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Martijn van Oosterhout wrote:
> I remember a while back someone posted a graphs showing a scalability
> of postgresql for various versions (I think 8.0 to 8.4). I've tried to
> find this image again but havn't been able to locate it. Does anyone
> here remember?
>

http://suckit.blog.hu/2009/09/29/postgresql_history

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us

On Wed, Feb 24, 2010 at 09:13:36PM -0500, Greg Smith wrote:
> Martijn van Oosterhout wrote:
>> I remember a while back someone posted a graphs showing a scalability
>> of postgresql for various versions (I think 8.0 to 8.4). I've tried to
>> find this image again but havn't been able to locate it. Does anyone
>> here remember?
>>
>
> http://suckit.blog.hu/2009/09/29/postgresql_history

Yes, that's the one, thank you.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Greg Smith, 25.02.2010 03:13:
> Martijn van Oosterhout wrote:
>> I remember a while back someone posted a graphs showing a scalability
>> of postgresql for various versions (I think 8.0 to 8.4). I've tried to
>> find this image again but havn't been able to locate it. Does anyone
>> here remember?
>
> 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
ifmaybe 8.4.2 fixed this) 

Thomas

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

Greg Smith, 25.02.2010 17:47:
> 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.

Thanks for the detailed answer!

Regards
Thomas