Обсуждение: 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