powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
25 сообщений из 156, страница 2 из 7
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572485
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa
Отличие табличных пространств DMS от SMS, кеширование ОС и ряд других вещей таково, что вы минимум не ухудшите выполнение пресловутого 23-го запроса на любых настройках.
Имею в виду результат замены SMS на DMS и т.п.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572819
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наверное, я всё же нифига не понимаю сути этого теста...

Там писали ( http://article.gmane.org/gmane.comp.db.firebird.russian/2156/match=dbgen)

"Тот самый update lineitem set l_comment = trim(l_comment)
- 251 секунда."

Я использовал вместо trim rtrim (ну нету в DB2 просто trim) -
time db2 "update lineitem set l_comment = rtrim(l_comment)"
DB20000I The SQL command completed successfully.

real 0m45.509s

При том, что машинка у меня заметно слабее - Athlon XP 1800+, памяти 384МБ, и база и её логи находятся на одном древнем IBMовском IDE диске.

Что я делаю не так?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573289
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Наверное, я всё же нифига не понимаю сути этого теста...

Потому что читать нужно всё ветку было. Это запрос вообще никакого отношения к тестам не имеет, а возник из-за трудностей с этим запросом на ASA в силу определённых настроек.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573303
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS?

В курсе, применительно к этому тесту особого эффекта не имели. Потом два раза одно и тоже говорить серверу выходило за рамки теста. Точно также как и ручное планирование в IB7.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573304
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А.
Ну извиняйте, как говорится-не осилил потому что много букв.
И ещё раз извините.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573323
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Архив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573346
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ребята, вы только не забывайте про то, что тесты эти Олег проводил на своём энтузиазме прежде всего для себя и для узкой группы людей, которые тусуются в известной конференции.

Изначально хотели сравнить IB/FB/Ya разных версий между собой, а потом ради интереса захотелось померяться письками с ораклом и т.д.

Тесты неофициальные, Олег широкой общественности ничего никому громогласно не заявлял, вы сами нашли этот тест и раздули этот топик. Так что вы с ним помягче - не может человек всё знать.

А вобще-то на тестах никто не обделался особо кроме IB.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573371
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS?

В курсе, применительно к этому тесту особого эффекта не имели. Потом два раза одно и тоже говорить серверу выходило за рамки теста.

Это не одно и то же.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573373
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это время выполнения запроса?
Тогда с запросом 2 как-то плохо.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573399
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaАрхив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно.
DB2 оказалась хуже Oracle. Чем не проблема?

;-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573433
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Это не одно и то же

Что не одно и тоже?

C точки зрения разработчика OPTIMIZE FOR n ROWS должно использоваться в обычных select когда требуется быстрый отклик при выборке первых n записей.

Когда я говрю серверу FETCH FIRST x ROWS ONLY, я уже подразумеваю что сервер будет оптимизировать мне выборку именно x значений.

Если бы мне требовалось быстрее отобрать n записей из x, где n существенно меньше чем x то одновременное указание обоих конструкций для одного запроса имело бы смылс. У меня отбирались все x записей, т.е. n = x. Следовательно OPTIMIZE FOR n ROWS мне нафиг не нужно. Если логика DB2 иная, то сами буратины :-).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573447
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Это время выполнения запроса?

Угу

>Тогда с запросом 2 как-то плохо.

У кого? :-), там их много.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573500
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У DB2.
План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573511
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa>
C точки зрения разработчика OPTIMIZE FOR n ROWS должно использоваться в обычных select когда требуется быстрый отклик при выборке первых n записей.

Когда я говрю серверу FETCH FIRST x ROWS ONLY, я уже подразумеваю что сервер будет оптимизировать мне выборку именно x значений.


Логично ожидать именно такого поведения. Беда в том, что реализовано это не так. Об этом говорили сами ibm-еры в их ньюсгруппе.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573603
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо.

Согласись, что я не должен был проверять что термин "белое" в DB2 на самом деле означает "серое", и выяснить это можно в news-группе от разработчиков DB2. Написал "белое", так делайте его "белым", я прочее оставляйте для маркетинга и рекламы. Радует что "серость" наверно проявляется при обработке существенно больших объёмов данных чем у меня в тесте.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573613
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeУ DB2.
План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе.

Порядок тот же, что и требовалось доказать. Так что притензии не ко мне а к IBM :-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573636
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gold
Тесты неофициальные, Олег широкой общественности ничего никому громогласно не заявлял, вы сами нашли этот тест и раздули этот топик. Так что вы с ним помягче - не может человек всё знать.
А вобще-то на тестах никто не обделался особо кроме IB.

Собственно я сразу и сказал что специально ничего затачивать в серверах под эти 22 запроса не буду. Цель исследования общая оценка эффективности движков на простых sql запросах без ручной доводки до максимального быстродействия прежде всего на IB движках, а уж потом я добавил прочие сервера чтобы было понятно где находится FB2 и что делать.

Потом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573743
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaТогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо.

Согласись, что я не должен был проверять что термин "белое" в DB2 на самом деле означает "серое", и выяснить это можно в news-группе от разработчиков DB2. Написал "белое", так делайте его "белым", я прочее оставляйте для маркетинга и рекламы. Радует что "серость" наверно проявляется при обработке существенно больших объёмов данных чем у меня в тесте.

Видите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573767
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaСобственно я сразу и сказал что специально ничего затачивать в серверах под эти 22 запроса не буду. Цель исследования общая оценка эффективности движков на простых sql запросах без ручной доводки до максимального быстродействия прежде всего на IB движках, а уж потом я добавил прочие сервера чтобы было понятно где находится FB2 и что делать.

Потом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации.

Как я понимаю, опубликовать скрипты и настройки базы вы отказываетесь.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573829
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573874
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaВидите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал.

Т.е. мне как разработчику нуджно говорить DB2: дай мне только 100 записей, не ты меня поняла, только 100 запсей... что непонятно, щас пну если не дашь только 100 записей ;-)

Уже не смешно. Нахрена тогда байки про навороченность оптимизатора DB2 сочинять, если он не в состоянии сам сооброзить что если сказали отбирать только 100 записей, так и оптимизировать запрос нужно под 100 записей. Ты сам то вдумайся в то что пишешь. И зачем тогда приводить ссылку на обсуждение этой пробемы с разработчиками DB2, когджа это только подтвержадает её существование, т.к. в противном случае на это обратил внимание только я, а выходит и другие товарищи уже обращали внимание на эту проблему.

Подсказка оптимизатору нужна тогда, когда явные критерии отбора данных указанные в запросе не позволяют однозначно выбрать оптимальный план. Какая неоднозначность может быть в конструкции "Отобрать только первые 100 записей и ВСЁ." Это уже не подсказка, а ручное планирование запроса, что условиями теста не допускалосось.... занавес.

P.S. Начёнм лепить хинты к DB2, я прилеплю хинты к ORA/MS/IB-клонам и что тогда?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573935
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рассмотрим запрос:
Код: plaintext
1.
   select * from tbl order by b fetch first  100  rows only

И такой:
Код: plaintext
1.
   select * from tbl where b>=:c fetch first  100  rows only

И такой:
Код: plaintext
1.
   select * from tbl where b>=:c order by b fetch first  100  rows only optimize  10  rows only


И вот такой:
Код: plaintext
1.
   select * from tbl where b>=:c order by b optimize for  10  rows

во всех приведенных случаях планы доступа будут разными с зависимости от наличия нужных индексов и правильности сбора статистики. Вариантов - просто миллион... мне чета даже лень писать все...
нет определенно лень... ((

optimize for - говорит по скольку записей будет попадать на станцию из результирующего набора, который находится на сервере. Набор будет достраиваться динамически (в некоторых случаях).
fetch first - определяет размер этого самого результирующего набора.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573997
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaЗдесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю.

По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574085
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки).

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
select
        s_acctbal,
        s_name,
        n_name,
        p_partkey,
        p_mfgr,
        s_address,
        s_phone,
        s_comment
from
        part p,
        supplier,
        partsupp,
        nation,
        region
where
        p_partkey = ps_partkey
        and s_suppkey = ps_suppkey
        and p_size =  15 
        and p_type like '%BRASS'
        and s_nationkey = n_nationkey
        and n_regionkey = r_regionkey
        and r_name = 'EUROPE'
        and ps_supplycost = (
                select
                        min(ps_supplycost)
                from
                        partsupp,
                        supplier,
                        nation,
                        region
                where
                        p.p_partkey = ps_partkey
                        and s_suppkey = ps_suppkey
                        and s_nationkey = n_nationkey
                        and n_regionkey = r_regionkey
                        and r_name = 'EUROPE'
        )
order by
        s_acctbal desc,
        n_name,
        s_name,
    p_partkey
FETCH FIRST  100  rows ONLY
OPTIMIZE FOR  100  ROWS
;



execution started at timestamp  2006 - 03 - 01 - 17 . 04 . 24 . 613000 
found [ 1 ] SQL statements from the input file
Recommending indexes...
total disk space needed for initial set [   77 , 779 ] MB
total disk space constrained to         [  337 , 398 ] MB
Trying variations of the solution set.
Optimization finished.
   9   indexes in current solution
 [ 660810 , 3125 ] timerons  (without recommendations)
 [ 1702 , 1033 ] timerons  (with current solution)
 [ 99 , 74 %] improvement


--
--
-- LIST OF RECOMMENDED INDEXES
-- ===========================
-- index[1],   19,329MB
   CREATE INDEX "VVM     "."IDX603011205030000" ON "VVM     "."PART" ("P_SIZE" ASC, "P_MFGR" ASC, "P_TYPE" ASC, "P_PARTKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."PART" FOR INDEX "VVM     "."IDX603011205030000" ;
   COMMIT WORK ;
-- index[2],   27,493MB
   CREATE INDEX "VVM     "."IDX603011204410000" ON "VVM     "."PARTSUPP" ("PS_PARTKEY" ASC, "PS_SUPPLYCOST" ASC, "PS_SUPPKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."PARTSUPP" FOR INDEX "VVM     "."IDX603011204410000" ;
   COMMIT WORK ;
-- index[3],    0,196MB
   CREATE UNIQUE INDEX "VVM     "."IDX603011204390000" ON "VVM     "."SUPPLIER" ("S_SUPPKEY" ASC) INCLUDE ("S_NATIONKEY") ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."SUPPLIER" FOR INDEX "VVM     "."IDX603011204390000" ;
   COMMIT WORK ;
-- index[4],    0,013MB
   CREATE INDEX "VVM     "."IDX603011204270000" ON "VVM     "."REGION" ("R_NAME" ASC, "R_REGIONKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."REGION" FOR INDEX "VVM     "."IDX603011204270000" ;
   COMMIT WORK ;
-- index[5],    0,013MB
   CREATE INDEX "VVM     "."IDX603011204310000" ON "VVM     "."NATION" ("N_REGIONKEY" ASC, "N_NATIONKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."NATION" FOR INDEX "VVM     "."IDX603011204310000" ;
   COMMIT WORK ;
-- index[6],   27,493MB
   CREATE INDEX "VVM     "."IDX603011204430000" ON "VVM     "."PARTSUPP" ("PS_SUPPLYCOST" ASC, "PS_PARTKEY" ASC, "PS_SUPPKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."PARTSUPP" FOR INDEX "VVM     "."IDX603011204430000" ;
   COMMIT WORK ;
-- index[7],    3,216MB
   CREATE UNIQUE INDEX "VVM     "."IDX603011205400000" ON "VVM     "."SUPPLIER" ("S_SUPPKEY" ASC) INCLUDE ("S_ACCTBAL", "S_COMMENT", "S_PHONE", "S_ADDRESS", "S_NAME", "S_NATIONKEY") ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."SUPPLIER" FOR INDEX "VVM     "."IDX603011205400000" ;
   COMMIT WORK ;
-- index[8],    0,013MB
   CREATE UNIQUE INDEX "VVM     "."IDX603011205350000" ON "VVM     "."NATION" ("N_NATIONKEY" ASC) INCLUDE ("N_NAME", "N_REGIONKEY") ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."NATION" FOR INDEX "VVM     "."IDX603011205350000" ;
   COMMIT WORK ;


--
--
-- RECOMMENDED EXISTING INDEXES
-- ============================
-- RUNSTATS ON TABLE "VVM     "."NATION" FOR INDEX "VVM     "."NATION_PK" ;
-- COMMIT WORK ;
-- RUNSTATS ON TABLE "VVM     "."PARTSUPP" FOR INDEX "VVM     "."PARTSUPP_PK" ;
-- COMMIT WORK ;
-- RUNSTATS ON TABLE "VVM     "."REGION" FOR INDEX "VVM     "."REGION_PK" ;
-- COMMIT WORK ;
-- RUNSTATS ON TABLE "VVM     "."SUPPLIER" FOR INDEX "VVM     "."SUPPLIER_PK" ;
-- COMMIT WORK ;


--
--
-- UNUSED EXISTING INDEXES
-- ============================
-- DROP INDEX "VVM     "."PART_BRAND_CONTAIN";
-- DROP INDEX "VVM     "."PART_NAME";
-- DROP INDEX "VVM     "."PARTSUPP_SUPPKEY";
-- DROP INDEX "VVM     "."SUPPLIER_NATIONKEY";
-- ===========================
--

 31  solutions were evaluated by the advisor
DB2 Workload Performance Advisor tool is finished.

Using user id as default schema name. Use -n option to specify schema
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574202
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman[quot olegloa]По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю.

Для тех кто не в теме. От меня был комментарий, что те кто мог получали 80% от ОЗУ под свои нужды, в том числе и от DB2 и размер кэшей пулов и пр у всех серверов настраивался.

Если не в курсе подробностей, то пишите в оригинальную конфу.
...
Рейтинг: 0 / 0
25 сообщений из 156, страница 2 из 7
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]