Re: Performance evaluation of PostgreSQL's historic releases

Поиск
Список
Период
Сортировка
Искать
От
Greg Smith
Тема
Re: Performance evaluation of PostgreSQL's historic releases
Дата
Msg-id
alpine.GSO.2.01.0909291753010.5539@westnet.com
Ответ на
Список
Дерево обсуждения
Performance evaluation of PostgreSQL's historic releases György Vilmos <vilmos.gyorgy@gmail.com>
Re: Performance evaluation of PostgreSQL's historic releases Simon Riggs <simon@2ndQuadrant.com>
Re: Performance evaluation of PostgreSQL's historic releases Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: Performance evaluation of PostgreSQL's historic releases György Vilmos <vilmos.gyorgy@gmail.com>
Re: Performance evaluation of PostgreSQL's historic releases Amitabh Kant <amitabhkant@gmail.com>
Re: Performance evaluation of PostgreSQL's historic releases György Vilmos <vilmos.gyorgy@gmail.com>
Re: Performance evaluation of PostgreSQL's historic releases Greg Smith <gsmith@gregsmith.com>
Re: Performance evaluation of PostgreSQL's historic releases György Vilmos <vilmos.gyorgy@gmail.com>
Re: Performance evaluation of PostgreSQL's historic releases Scott Marlowe <scott.marlowe@gmail.com>
Re: Performance evaluation of PostgreSQL's historic releases György Vilmos <vilmos.gyorgy@gmail.com>
On Tue, 29 Sep 2009, Gy?rgy Vilmos wrote:

> I've done a benchmark of recent versions of PostgreSQL's last five major 
> releases to see, how performance has changed during the past years from 
> version to version.

Your comments suggest V8.4 moves backwards as far as performance goes, 
which is a bit misleading.  A more fair characterization would be to 
disclaim 8.4 as potentially being slower on the very simple benchmarks you 
ran, not necessarily in general.

What actually happened is some features were retuned to give better 
results on difficult queries (increasing default_statistics_target is the 
main example there), and one of the major maintenance tasks was removed 
(adjusting the max_fsm_* parameters).  These and the other 8.4 changes 
that touched performance added a small amount of overhead for simple 
queries, but in the situations where they help the gain can be big.

Had you instead benchmarked a complicated query where the statistics 
change caused the default behavior to provide better query plans, or you 
had a deletion-heavy workload where 8.3 had trouble maintaining database 
free space, you could have seen significantly better performance on 8.4. 
The improvements in that version just don't help trivial examples like the 
sysbench ones you ran.

P.S. On your write-heavy tests, increasing checkpoint_segments a lot 
should improve overall performance, if you re-test at some point.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-general по дате отправления
От: Tom Lane
Дата:
Сообщение: Re: Data file recovery
От: Sam Mason
Дата:
Сообщение: Re: computed values in plpgsql
FAQ