ProgMannЧто с тестами TPC-H и др. у Линтер, PostgreSQL, MySQL и др.?
Что-то на сайте TPC ничего про них нет

Запустите HummerDB и сравните на своем сервере
Удобные попугаи для сравнения
Более сложные сравнения требуют генератора тестовой нагрузки, специфичной для вашего бизнеса.

Victor MetelitsaVadim Lejnin,

После того, как я немного покопался внутри HammerDB, стал сомневаться, что им в самом деле можно сравнивать одну СУБД с другой. По крайней мере, он подозрителен. И он не полностью реализует TPC-C (а, может, и H). Тем не менее, всё равно Линтеру стоило бы его поддержать. А сам HammerDB стоило бы переписать на... ну, хотя бы, на Java.
Я не считаю что это TPC/C - это попугаи
Однако эти попугаи вполне могут применяться для сравнивания двух БД на одной машине
Или посмотреть для выбора несколько серверов

На OraHummer раньше можно было загрузить ему event 10046 trace file,
и он генерил TCL код для тестирования

Я даже когда-то писал генератор нагрузки для несложного приложения используя такой метод

Но обычно не заморачиваюсь, и использую тот TPC который он предлагает
Запускаю от 5-30 клиентов обычно хватает
Для оценки обычно даже не дожидаюсь окончания теста, достаточно посмотреть как он ведет себя под нагрузкой.

Victor Metelitsakdvказалось бы, диски сравнивают хотя бы IOMeter-ом, и никто от натуги не помер. А вот тест СУБД запустить - почему-то адски сложная задача.

p.s. я не говорю, что надо запускать тест альтернативных для себя СУБД. Достаточно уметь запускать тест для своей СУБД, чтобы понимать, чем новый сервер лучше старого, или чем новые диски лучше-хуже старых, или что на сервере что-то произошло с производительностью, и т.д.
Для начала, надо понимать, что такое IOmeter, что он меряет, смысл тех цифр, которые он даёт, и применимость к своей практической задаче. С тестом СУБД ещё сложнее, потому что он много сложнее IOmeter'а. Бездумный запуск тестов - бесполезная трата времени.

Задача тестирования производительности, вообще задача нетривиальная
Пример с CentOS показателен. Поэтому RedHat или OEL сертифицированы под Oracle, а Fedora нет.
И это только настройка ОС. Настройка БД под конкретные приложения как правило отдельный проект. Другое дело, что буржуи, которые умеют считать деньги предпочитают переплатить за железо, чем нанимать высококласных и очень дорогих спецов для систем малой и средней нагруженности.
Все меняется для критических систем которые работают в режиме максимально возможной нагрузки для существующего железа.

Кроме выбора железа и платформы, на выбор влияют такие факторы как доступность необходимых спецов, наличие инфраструктуры поддержки.
Например в начале-середине 90-х в России сложилась парадоксальная ситуация,
когда грамотные администраторы VAX стоили дешевле грамотных администраторов Windows
Насколько я знаю, сейчас мало доступны администраторы DB2, поэтому с ней в России стараются не связываться.

В Германии и Франции, большой выбор фирм которые оказывают качественную поддержку и обучение для OpenSource продуктов, поэтому бизнес рассматривает эти решения при выборе.
Мой однокурсник, в Германии до последнего времени работал в такой компании.

А у нас, до последнего времени, если предложить PostgreSQL как возможное решение при проекте было неприлично. Банальный вопрос - кто будет поддерживать такое решение подвисал в воздухе.