From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Performance comparison |
Date: | 2010-02-25 17:00:25 |
Message-ID: | hm6ab8$k9v$1@dough.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff | 2010-02-25 17:03:47 | Re: Curious plperl behavior |
Previous Message | Greg Smith | 2010-02-25 16:47:36 | Re: Performance comparison |