Re: ??????????????? ?????????? ?? ????? TPCR (YA/FB/ORA/MS/PG)
"Horsun Vlad" <[EMAIL PROTECTED]> wrote: "Dmitry Yemanov" ... > select > s_suppkey, > s_name, > s_address, > s_phone, > total_revenue > from > revenue left join supplier on s_suppkey = supplier_no revenue0 ? ???- :-) ? ? ?, ??? ??? ?. ? ??? ? ?? - revenue. ??? ??? ??? ? ? ? - ?? ??? :-) -- ??? ??
Re: ??????????????? ?????????? ?? ????? TPCR (YA/FB/ORA/MS/PG)
Привет, Dmitry! Вы пишешь 16 февраля 2006: DY> ???- :-) ? ? ?, ??? ??? ?. ? ??? ? Фсё! Теперь и спички кончились. В темноте одиноко белеет чернотой вопросительный знак... -- With best regards, Alex Cherednichenko.
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Цифры во вложении. Итоги (комментарии) будут позжее вместе с тестом классиков и IB7. Предварительные выводы. 1) Необходимо подправить код кэша в FB2, т.к. при увеличении числа страниц иммем тормоза 2) Слухи о тормознутости PG сильно приувеличины :-) БД - TPCR c коэф. 1. Все запросы переписаны на обычные (т.е. без процедур) Клиент - прога дёргающая запросы через ODBC Ýòà ñòðàíèöà èñïîëüçóåò ðàìêè, íî âàø îáîçðåâàòåëü èõ íå ïîääåðæèâàåò.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Привет, Horsun! Вы пишешь 14 февраля 2006: HV> И где же HV> ? Мабуть далi буде... -- With best regards, Alex Cherednichenko.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" ... > > "Oleg LOA" ... > > Цифры во вложении. > > > > Итоги (комментарии) будут позжее вместе с тестом классиков и IB7. > > Опа, облажался забыл основные файлы с цифрами :-):-):-) - после обеда довыкладываю. Угу, и про zip\rar\etc не забудь ;) -- Хорсун Влад
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Опа, облажался забыл основные файлы с цифрами :-):-):-) - после обеда довыкладываю. Уже где-то можно посмотреть результаты?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"sasha" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > > Опа, облажался забыл основные файлы с цифрами :-):-):-) - после обеда довыкладываю. > > Уже где-то можно посмотреть результаты? Да ты што? Чтобы хорошо пообедать нужно никак не меньше суток...
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Voroshin" wrote in message news:[EMAIL PROTECTED] > > > Да ты што? Чтобы хорошо пообедать нужно никак не меньше суток... Именно :-) tpcrtest.rar Description: Binary data
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: Именно :-) Если бы не кривой план на 16-м запросе, все было бы очень даже красиво. -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
А вы какой PG сравнивали? 8.1 или 8.0? И ещё там я не понял результатов на вкладке FB/PG - где чьи? И по IB7 что-то невесёлое...
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
> 2) Слухи о тормознутости PG сильно приувеличины :-) Явно слухи, по крайней мере экстракт метаданных на нем проходит в несколько раз быстрее чем на других серверах, а про остальное я не в курсе. :-)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Oleg LOA" wrote: >> >> Именно :-) > > Если бы не кривой план на 16-м запросе, все было бы очень даже красиво. Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-) P.S. Я ещё не проверял 15 запрос с раскомментированным view.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Что значит где? Там всен страницы нормально подписаны. Я так понимаю что сравнивались FB1.5.3 и PG 8.1.2, так?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-) Оптимизатор уже в работе. У меня 14 и 16 запросы в блокнотике давно записаны, но все руки не доходили. Я на TPC-R каждое изменение оптимизатора тестирую :-) -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Oleg LOA" wrote: >> >> Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-) > > Оптимизатор уже в работе. У меня 14 и 16 запросы в блокнотике давно С кэшем как я понял предложено мне разбираться? Типа сам нашёл - сам и разбирайся :-):-):-), у Влада как я понял замедление не наблюдается.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: С кэшем как я понял предложено мне разбираться? Заметьте, не я это предложил (с) :-))) у Влада как я понял замедление не наблюдается. Я еще у себя попробую. Не не сегодня. -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Sergey Nikolaenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hello, Oleg! > You wrote on Wed, 15 Feb 2006 11:47:45 +0300: > ??>> > ??>> Да ты што? Чтобы хорошо пообедать нужно никак не меньше суток... > > Олег, а не думал попробовать на халявной DB2 ? > > Весьма любопытсвенно было бы узнать результаты Мона протестировать, ссылку дашь, аль самому искать?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: Ты мне скажи почему 14-й при смене размера кэша стал тормозить? Пока не скажу. Не все сразу :-) Или у тебя там в оптимизаторе это учитывается? Никак нет. -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
http://www-306.ibm.com/software/data/db2/udb/db2express/download.html
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" ... > С кэшем как я понял предложено мне разбираться? Типа сам нашёл - сам и разбирайся :-):-):-), Ну, если ты это уже когда-то правил, то тебе и карты в руки ;) Но я всё-таки не верю, что это код кеша виноват, сорри... Наш IO, конечно, далеко не оптимален и не умён, но тормозов от р-ра кеша я не вижу. Хотя очень хотел бы увидеть - это дало бы шанс повысить скорость до существенной переделки IO ;) > у Влада как я понял замедление не наблюдается. Это такой комплимент ? Спасибо :-) -- Хорсун Влад
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
> http://www-306.ibm.com/software/data/db2/udb/db2express/download.html Или это: http://download2.boulder.ibm.com/sdfdl/v2/regs2/db2pmopn/Express-C/Xa.2/Xb.TNNkeJrCP1J3kxTqhrfe9w/Xc.db2exc_NT_x86.zip/Xd./Xf.Ltr.D1vk/Xg.3229015/Xi.dm-db2express/XY.regsrvs/XZ.l_nPDwR7fPKsRFsvh_1BQY_Dp48/db2exc_NT_x86.zip не знаю отдаст ли без регистрации.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote: А вот с 16-м причина понятна - я отключил использование индексов для NOT IN, в результате чего коррелированный подзапрос пошел натуралом. Следствие налицо. Сейчас буду думать, что с этим делать. Вроде заборол. Теперь NOT IN с индексами должен корректно работать. И быстро, вдобавок :-) -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" ... > > "Dmitry Yemanov" > wrote: > > > > А вот с 16-м причина понятна - я отключил использование индексов для NOT > > IN, в результате чего коррелированный подзапрос пошел натуралом. Следствие > > налицо. Сейчас буду думать, что с этим делать. > > Вроде заборол. Теперь NOT IN с индексами должен корректно работать. И > быстро, вдобавок :-) Ну вот - хоть кто-то что-то делает ;) -- Хорсун Влад
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: > > Ты мне скажи почему 14-й при смене размера кэша стал тормозить? Поигрался щаз немного с кешем. Вывод: тормоза начинаются при конкуренции кеша FB с кешем виндов за ОЗУ. Т.е. стоит поставить кеш FB ближе к размеру доступной памяти, как сразу наблюдаются жуткие тормоза. Ставим NO_BUFFERING - тормоза исчезают. Впрочем, это никак не объясняет ситуацию с Дятлом :-) Ради интереса просмотрел diff для твоих cch.c и dpm.c - никаких функциональных отличий от FB2 не нашел. -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Oleg LOA" <[EMAIL PROTECTED]> wrote: >> >> Ты мне скажи почему 14-й при смене размера кэша стал тормозить? > > Поигрался щаз немного с кешем. Вывод: тормоза начинаются при конкуренции У меня стоит флаг FILE_FLAG_RANDOM_ACCESS, как на файл БД, так и на файлы сортировки. В FB2 только на файл БД, может при сортировках винда вытестняет фалом сортировки из файлового кэша файл БД?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" ... > "Dmitry Yemanov" ... > > "Oleg LOA" wrote: > >> > >> Ты мне скажи почему 14-й при смене размера кэша стал тормозить? > > Результаты IB7 ... > > 3.2 ГГц/ 2 Гб А каши ты ему сколько дал ? -- Хорсун Влад
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Oleg LOA" <[EMAIL PROTECTED]> wrote: >> >> Ты мне скажи почему 14-й при смене размера кэша стал тормозить? > > Поигрался щаз немного с кешем. Вывод: тормоза начинаются при конкуренции > кеша FB с кешем виндов за ОЗУ. Т.е. стоит поставить кеш FB ближе к размеру > доступной памяти, как сразу наблюдаются жуткие тормоза. Ставим > NO_BUFFERING - тормоза исчезают. Я вот тоже сидел и медитировал над воспоминаниями - ЧТО Я ТАКОЕ СДЕЛАЛ чтобы так работало :-):-):-):-). Но проблему-то это никак не решает. Какой тогда был смысл разрешать ставить 128К страниц кэша если толку от этого только в минус?! > Впрочем, это никак не объясняет ситуацию с Дятлом :-) Ради интереса > просмотрел diff для твоих cch.c и dpm.c - никаких функциональных отличий от > FB2 не нашел. Угу, возможно это может быть связано с различным алгоритмом работы с памятью/временным фалом при сортировке. Правда в наиболлее тормознутом запросе 9 сортировкой вроде много и не жрётся??? В любом случае с эти надо что-то делать, по крайней мере я бы пока уменьшил максимальный размер кэша с 128K.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: > > Результаты IB7 Олег, прогони при возможности сегодняшний снапшот 2.0 (с исправленным 16-м запросом) с кешем в 10К буферов, плиз. С кешем будем отдельно разбираться, но меня пока оптимизатор интересует. -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Oleg LOA" ... >> "Dmitry Yemanov" ... >> > "Oleg LOA" wrote: >> >> >> >> Ты мне скажи почему 14-й при смене размера кэша стал тормозить? >> >> Результаты IB7 > ... >> >> 3.2 ГГц/ 2 Гб > >А каши ты ему сколько дал ? 32K страниц
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Oleg LOA" <[EMAIL PROTECTED]> wrote: >> >> Результаты IB7 > > Олег, прогони при возможности сегодняшний снапшот 2.0 (с исправленным 16-м > запросом) с кешем в 10К буферов, плиз. С кешем будем отдельно разбираться, > но меня пока оптимизатор интересует. Хорошо сделаю. Ты о влиянии FILE_FLAG_RANDOM_ACCESS не думал (файлы сортировки)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello, Oleg! > > я понял. Тест Алексея с процедурой. А у тебя - с view. План получается такой: > PLAN SORT (MERGE (SORT (SUPPLIER ORDER RDB$PRIMARY2), > SORT (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE) Да именно он
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: > > > У меня стоит флаг FILE_FLAG_RANDOM_ACCESS, как на файл БД, > так и на файлы сортировки. В FB2 только на файл БД, может при > сортировках винда вытестняет фалом сортировки из файлового кэша > файл БД? Возможно. Только не думаю, что FILE_FLAG_RANDOM_ACCESS как-либо влияет на вытеснение. Скорее то, что YA полагается только на кеширование временных файлов осью, а FB сначала держет времянки в памяти сама, а только потом выделяет место во временном файле. Но дефолтные 64 метра буфера сортировки на фоне 2 гигов ОЗУ как бы не должны так сильно влиять. Я могу для проверки подготовить билд, который со времянками работает аналогично YA, но честно говоря сомневаюсь в том, что это исправит ситуацию. -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > что-то я перестал понимать, о каком тесте вы говорите. > IB 7.5 не кушает планы на 3-ем и 20-ом запросе. > Решение тут > http://ibdeveloper.com/tests/tpc-r/some-comments-on-query-n-3/ > > откуда там проблема с 15-ым запросом? Дим, ВНИМАНИЕ!!! Посмотри на мои запросы, они все через VIEW!!! Никаких процедур и прочих извратов - метаданные в архиве с результатами.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: > > может при сортировках винда вытестняет У тебя в табличке первый запрос выполняется либо так же на 100К (1.5), либо чуток тормозит (2.0). А третий запрос на 100К выполняется значительно медленнее. Однако, размер сортировки у первого на три порядка больше, чем у третьего. Так что думаю, что сортировку стоит исключить из рассмотрения. -- Дмитрий Еманов
Re: оПЕДБЮПХРЕКЭМШЕ ПЕГСКЭРЮРШ ОН РЕЯРС TPCR (YA/FB/ORA/MS/PG)
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote: > >> Кроче мне нужно как-то выполнить 15-й запрос на IB7 без процедуры, > > и за время меньшее чем неделя :-). Есть варианты?! > > боюсь что нет. select s_suppkey, s_name, s_address, s_phone, total_revenue from revenue left join supplier on s_suppkey = supplier_no where s_suppkey = supplier_no and total_revenue = ( select max(total_revenue) from revenue ) order by s_suppkey; -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" ... > select > s_suppkey, > s_name, > s_address, > s_phone, > total_revenue > from > revenue left join supplier on s_suppkey = supplier_no Íàâåðíîå revenue0 ? -- Õîðñóí Âëàä
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: >> Олег, а не думал попробовать на халявной DB2 ? >> Весьма любопытсвенно было бы узнать результаты > Мона протестировать, ссылку дашь, аль самому искать? Ну, если уж такой зоопарк собираешь, то вот еще для коллекции ASA9 Developer Edition: http://crm.sybase.com/sybase/www/iAS/developer_download_registration.jsp?tpl=ias Если лень регистрироваться и ждать ключика, то вот прямая ссылка: http://download.sybase.com/eval/dev/Win32/SA902_Win32_EN_Developer.exe ключик могу мылом отправить, если интересно.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Добавил DB2 2 DY - последняя собрка нормально not in отрабатывает. Осталось решить проблему с оригинальным 15 запросом. log.rar Description: Binary data
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote: > > Разбираюсь. В общем, там две проблемы с определением инвариантности подзапросов. Первая - логика не для всех видов подзапросов работает. Это я вроде исправил. Теперь, если тело "revenue" подставить в виде derived table, то 15-й запрос летает. Однако, оригинальный вариант не работает из-за второй траблы - инвариантность спотыкается на сочетании агрегатов и вьюх в подзапросах. Есть одна маленькая разница между обработкой чистого RSE и вьюхи и она портит всю кашу. Диагноз мне ясен, но красивого решения пока нет. Но наш "Варяг" так просто не сдается :-) -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Dmitry Yemanov" <[EMAIL PROTECTED]> > wrote: >> > подзапросах. Есть одна маленькая разница между обработкой чистого RSE и > вьюхи и она портит всю кашу. Диагноз мне ясен, но красивого решения пока > нет. Но наш "Варяг" так просто не сдается :-) Косяки с группировкой? Я прав?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" <[EMAIL PROTECTED]> wrote: > > Косяки с группировкой? Я прав? Косяком бы я это не назвал. Код правильный, просто для aggregate поверх view он по определению работать не может :-) -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Roman Rokytskyy" <[EMAIL PROTECTED]> wrote: > > можете сказать приблизительное время отработки 16-го запроса после того > как оптимизатору интеллект подправили? Точные цифры у Олега, я тест целиком не гонял. Должно быть 4-4.5 сек на кеше в 10К страниц. -- Дмитрий Еманов
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Roman Rokytskyy" > <[EMAIL PROTECTED]> wrote: >> >> можете сказать приблизительное время отработки 16-го запроса после того >> как оптимизатору интеллект подправили? > > Точные цифры у Олега, я тест целиком не гонял. Должно быть 4-4.5 сек на кеше > в 10К страниц. Порядок такой же как у Fb1.5/YA, точно не помню - тест и резлуьтаты дома. А почему такой вопрос возник?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Roman Rokytskyy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> Порядок такой же как у Fb1.5/YA, точно не помню - тест и резлуьтаты дома. Если есть спецы по ASA, то скажите мне где мне подкрутить руки, что бы он update по большой таблицы не делал мне несколько суток? А то я никак не могу для него подготовить данные TPCR. Данные залил, то нужно выполнить пару update по всем таблицам - так вот тормозит немерянно: уходит в IO и всё.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Привет, Dmitri! Вы пишешь 26 февраля 2006: DK> на sql.ru есть ASCRUS, если я не ошибся. DK> Большой популяризатор ASA в форуме IB/FB/YA :-) Больше известен как выдающийся гонщик ;) -- With best regards, Alex Cherednichenko.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: > Если есть спецы по ASA, то скажите мне где мне подкрутить руки, > что бы он update по большой таблицы не делал мне несколько суток? Я может мог бы чем-то помочь, но нужно видеть метаданные, запросы, параметры запуска сервера и т.п. почта alexgold эт inbox точка ru аська 284122821 P.S. у базы есть transaction log или сделал без него?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Привет, Dmitri! Вы пишешь 26 февраля 2006: >> Больше известен как выдающийся гонщик ;) DK> при всем этом он ASA очень неплохо знает. Насколько мы (профаны в оном), можем судить... -- With best regards, Alex Cherednichenko.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > на sql.ru есть ASCRUS, если я не ошибся. > > Большой популяризатор ASA в форуме IB/FB/YA :-) Читал пейджер, популяризации аргументированной не обнаружил. Пошёл углублённо читать документацию, однако обидно что с настройками по умолчанию такие косяки :-(
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Alex Cherednichenko пишет: >>> Больше известен как выдающийся гонщик ;) >> при всем этом он ASA очень неплохо знает. > Насколько мы (профаны в оном), можем судить... Не считая себя профаном в ASA, смею заверить, что ASCRUS действительно очень хорошо в нем разбирается.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Привет, Alexander! Вы пишешь 26 февраля 2006: AG> Не считая себя профаном в ASA, смею заверить... И шо, и справка имеется? (С) -- With best regards, Alex Cherednichenko.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: >> Большой популяризатор ASA в форуме IB/FB/YA :-) > > Читал пейджер, популяризации аргументированной не обнаружил. > Пошёл углублённо читать документацию, однако обидно что с настройками > по умолчанию такие косяки :-( Да вроде там все более чем нормально с умолчательными настройками. А про твой апдейт не имея пока практически никаких исходных данных для размышления я прислал тебе гипотезу - отсутствие PK на таблице. C нетерпением жду ответа, чтобы узнать угадал ли я.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: > я конечно понимаю праздники...но подозревать меня в отсутствии PK в > таблице? Я не подозреваю, я высказываю гипотезу :) Ибо странно сие, а с подобным проявлением уже сталкивался именно по причине отсутствия PK. Мне аж самому интересно стало несмотря не некоторый цейтнот. Нашел уже структуру данных TPCR. Но сейчас нечем скомпилять их заполнялку. P.S. А ASCRUS что-то не откликается. Вот он любит подобные тесты :)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Roman Rokytskyy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Олег, > Если не сложно, прогони плиз тесты с Ingress тоже. А то, как мне кажется, > где-то за пол-года его будут опять сильно популяризировать, а он нам > теоретический конкурент по опенсорсу. И где его взять в нормальном варианте? > Ну и если быть совсем наглым - было бы интересно посмотреть есть ли различия > по быстродействию у экспресс-версий Оракла и MSSQL. Тесты ora и mssql уже есть.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Alexander Goldun" wrote in message news:[EMAIL PROTECTED] > Oleg LOA пишет: > >> я конечно понимаю праздники...но подозревать меня в отсутствии PK в >> таблице? pk есть, твои рекомендации с добавлением страниц сделал - толку ноль. IO идт постарничный с фалом БД
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: > pk есть, твои рекомендации с добавлением страниц сделал - толку ноль. > IO идт постарничный с фалом БД Прям засада какая-то! Ставлю уже MSVC 6, попробую вспомнить как этим пользоваться, чтобы самому скомпилять dbgen и попробовать сие. Сколько записей в этой таблице? Что выдает SELECT @@version ? ASCRUS утверждает, что там на сайте лежит сырая версия 9.0.2, у которой поломали оптимайзер и надо ставить последний патч (ebf). У него такой же апдейт 10-милионной таблицы прошел за 400 сек. Страница в 2кб все-таки маловато, оптимальнее будет наверное 8кб для такой базы.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg LOA said the following on 27.02.2006 1:11: >> Если не сложно, прогони плиз тесты с Ingress тоже. А то, как мне кажется, >> где-то за пол-года его будут опять сильно популяризировать, а он нам >> теоретический конкурент по опенсорсу. > > И где его взять в нормальном варианте? http://opensourcefiles.ca.com/Windows/ingres-3.0.2.105-GA-win32.zip http://opensourcefiles.ca.com/Windows/ingres-3%5B1%5D.0.2.105-readme.zip http://opensourcefiles.ca.com/Windows/gettingstarted.pdf -- Oleg
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Так и не скомпилял я этот dbgen. Взял готовый для FB2.0 по адресу http://ibdeveloper.com/tests/tpc-r/how-to-run-tpc-r-based-test/ Сгенерил файлы с данными. Использовал ASA 9.0.2.3207 на Win2003, процессор Celeron 2.66 ггц, памяти 512 мб, винт обычный IDE. Создал базу с размером страницы 8 кб. Остальное - по-умолчанию. Запустил ее полностью по-умолчанию - командой dbeng9 tpcr.db Сделал ту таблицу lineitem Залил данные из файла стандартной командой LOAD TABLE - заливка 490 секунд, 6001215 записей Создал PK - 330 сек. Тот самый update lineitem set l_comment = trim(l_comment) - 251 секунда. За все это время максимальный размер кэша - 240 мб (по-умолчанию ASA динамически меняет размер кэша в зависимости от потребностей и наличия свободной памяти в системе) Использовавшийся комп был заментно нагружен и другими задачами, так что эксперимент далеко не слишком чистый. Если еще не потерял интерес, могу выдать: 1) последний EBF (9.0.2.3249, 75мб) 2) скрипт создания базы 3) скрипты загрузки таблиц из файлов *.tbl, которые сделал dbgen 4) командную строку для запуска бд можно и по-умолчанию использовать Правильно ли я понял, что в TPC-R просто меряется время однократного выполнения запосов 1.sql-22.sql?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Dmitri Kuzmenko пишет: > для запроса > update lineitem set field = trim(field); > > imho оптимизатор не имеет абсолютно никакого значения. Да, неактуален. Не знаю точный номер версии у Олега, но существенные "поломки" в 9.0.2 в начальных выпусках были - тогда достаточно много изменений вносилось. Почему они именно его выложили на сайт, не потрудившись хотя бы упомянуть про апгрейды - без понятия.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Alexander Goldun" wrote in message news:[EMAIL PROTECTED] > Тот самый update lineitem set l_comment = trim(l_comment) > - 251 секунда. Я нашел косяк. У меня обновлялись в одном update три поля из которых два были индексируемыми. Чёт там shipmomode и ещё какое-то varchar. Так вот при наличии индекса ASA уходит в глубокий IO при обновлении 6 МБ записей на lineitem. Создай все 4-е индекса на lineitem и выполни update по индексируемым полям. MS эту задачку решил за час. Сколько решаем мы узнаю вечером.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: >> Тот самый update lineitem set l_comment = trim(l_comment) >> - 251 секунда. > > Я нашел косяк. У меня обновлялись в одном update три поля из которых > два были индексируемыми. Чёт там shipmomode и ещё какое-то varchar. > Так вот при наличии индекса ASA уходит в глубокий IO при обновлении > 6 МБ записей на lineitem. > > Создай все 4-е индекса на lineitem и выполни update по индексируемым полям. Индексы нашел: create index lineitem_shipdate on lineitem(l_shipdate); create index lineitem_partkey_suppkey on lineitem(l_partkey, l_suppkey); create index part_brand_container_size on part(p_brand, p_container, p_size); create index lineitem_quantity_sm_si on lineitem(l_quantity, l_shipmode, l_shipinstruct); create index lineitem_shipmode_rd on lineitem(l_shipmode, l_receiptdate); Оно? Текст update дашь или самому придумать?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: >> Оно? > > Да > >> Текст update дашь или самому придумать? > > update lineitem set > > l_shipmode = l_shipmode || '', > l_shipinstruct = l_shipinstruct || ' ', > l_comment = l_l_comment || ' '; > > > Это trim наоборот :-) Или я туплю, или что-то проглядел. Индексы сделал - 1257 секунд на 4 индекса. Выполнил UPDATE - 610 секунд всего. Сейчас попробую запустить такое: update lineitem set l_shipmode = trim(l_shipmode) || '===', l_shipinstruct = trim(l_shipinstruct) || '===', l_comment = trim(l_comment) || '===' т.к. не искючено, что сказалось то, что база сделана с режимом ignore trailing blanks in comparison.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Alexander Goldun пишет: > Сейчас попробую запустить такое: > > update lineitem set > l_shipmode = trim(l_shipmode) || '===', > l_shipinstruct = trim(l_shipinstruct) || '===', > l_comment = trim(l_comment) || '===' > > т.к. не искючено, что сказалось то, что база сделана с режимом ignore > trailing blanks in comparison. так оно и есть. 7 часов 56 минут. Условия те же - Win2003, процессор Celeron 2.66 ггц, памяти 512 мб (ASA смог заполучить под кэш только 260мб), винт обычный IDE от Seagate, 160 гб. Файл БД сильно фрагментирован - 1071 фрагмент. Transaction log рядом с базой. Дисковое IO великовато - из этих 8 часов CPU Time серверного процесса в районе 20 минут, может даже меньше. Посмотрим, что покажут тесты TPC-R у Олега.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Добавил результаты ASA9, цифры говорят сами за себя. По поводу косяка с массовым обновлением lineitem на ASA9 - виноваты индексмы. Т.е. это явные грабле в ASA. Тотже Ya отработал запрос за пару минут, MS копался раздувая лог 1 час, ORA выполнил быстрее На этом тестирование заканчиваю. Положительный эффект есть - пару косяков в FB2 подправили. log.rar Description: Binary data
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: > По поводу косяка с массовым обновлением lineitem на ASA9 - виноваты индексмы. > Т.е. это явные грабле в ASA. Нашли способ как сократить это до 67 минут только настройками параметров. Виновата частая запись грязных страниц по причине слишком короткого интервала допустимого восстановления базы после сбоя. Не сказал бы что грабли, слишком специфичная задача. > Тотже Ya отработал запрос за пару минут, А вот это интересно, за счет чего такая резвость? Forced writes? Дилетантский вопрос: а не связано ли как-то замедление подобной операции у других серверов по сравнеию с FB с тем, что есть затраты на обеспечение той самой пресловутой Statement/transaction consistency? > MS копался раздувая лог 1 час, ORA выполнил быстрее Быстрее чем MS или быстрее Ya? > На этом тестирование заканчиваю. Положительный эффект есть - пару > косяков в FB2 подправили. А какими еще тестами пользуетесь в работе кроме TPC-R?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Alexander Goldun" wrote in message news:[EMAIL PROTECTED] > Дилетантский вопрос: а не связано ли как-то замедление подобной операции > у других серверов по сравнеию с FB с тем, что есть затраты на > обеспечение той самой пресловутой Statement/transaction consistency? Ora тоже пару минут выполнял. >> MS копался раздувая лог 1 час, ORA выполнил быстрее > > Быстрее чем MS или быстрее Ya? Как Ya. > А какими еще тестами пользуетесь в работе кроме TPC-R? Комплексное тестирование проводил только TPCR. А так у меня есть апака со сборником косяков -)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello, Oleg! > > Oleg LOA wrote: > >> Мы где-то 1.7 - 2 GB, ASA столько же. ORA/MS./PG от 4 до 6 GB. > > а db2? А х.з. Не думаю что больше чем у ORA/MS/PG. Ну и явно меньше чем у нас быть не может.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Вот уже фаны DB2 налетели. Ну не нравится им результат 2-го запроса и всё тут. http://www.sql.ru/forum/actualthread.aspx?tid=266639&pg=-1
Re: оПЕДБЮПХРЕКЭМШЕ ПЕГСКЭРЮРШ ОН РЕЯРС TPCR (YA/FB/ORA/MS/PG)
Karabas Barabas wrote: > OL> http://www.sql.ru/forum/actualthread.aspx?tid=266639&pg=-1 > > улыбнуло: "Что-то я там увидел тока новый начинающий какой-то форум по БД. > Значительно уступающий данному. Таких "тестов" наверняка полно и здесь" Не менее забавна поза насчёт штрейкбрейхества "ребят из Firebird", отбивающих хлеб у админов всяких монстров :) И вправду - изобрела одна скотина транзистер и вот, докатились до настольных конпутеров, который кажный козёл может купить и пользовать. И погибла в зародыше цивилизация гигантских арифмометров. А сколько механиков могли зарплату получать - кажен день на 15-м этаже в высоту что-то смазать, на 7-мом килОметре в длину гайку подтянуть... И форум действительно поганый - никто на Вы не величает, хуже и вправду найти трудно... А вообще-то меня идея сравнения серверов при помощи некоего универсального теста всегда наводила на иронию. Тест как сборник запросов, отражающих те или иные потребности реальных задач, безусловно полезен. Для выявления _у себя_ узких мест и последующей работы над ними. Да пофиг насколько у соседа в штанах толще или тоньше, главное - чтоб у нас было приемлемо для реалий. А достигаться это может разными средствами на разных серверах, посему результаты сравнения функционирования по дефолту - имхо чистой воды спортплощадка для ламеров от каждой общины, имеющих о сути тестов весьма приблизительное представление ;) -- Regards. Ded.
Re: оПЕДБЮПХРЕКЭМШЕ ПЕГСКЭРЮРШ ОН РЕЯРС TPCR (YA/FB/ORA/MS/PG)
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Karabas Barabas wrote: >> OL> http://www.sql.ru/forum/actualthread.aspx?tid=266639&pg=-1 >А вообще-то меня идея сравнения серверов при помощи некоего > универсального теста всегда наводила на иронию. Тест как сборник Самое главное тест так и задуман, почему некторые граждане решили что задача теста получить максимальную производительность каждого сервера я так и не понял. > запросов, отражающих те или иные потребности реальных задач, безусловно > полезен. Для выявления _у себя_ узких мест и последующей работы над > ними. Да пофиг насколько у соседа в штанах толще или тоньше, главное - И какой на него (тест) дал ссылку на sql.ru? Люди потестили подправили косяки у себя в FB2, нет прибежали товарищи и началось Чуствую пошлю всех в зад - как протестировал, так и протестировал. На общем фоне FB2 смотрится нормально, статью по косяку в ASA написть обещали - чего ещё хочет общественность мне не понятно? Очевидно углублённого изучения DB2 :-):-):-)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Ded пишет: > Не менее забавна поза насчёт штрейкбрейхества "ребят из Firebird", > отбивающих хлеб у админов всяких монстров :) Тоже позабавило. Хотел там на это ответить, да жаба задушила буквы тратить :) +1, как говорят на auto.ru :) > А вообще-то меня идея сравнения серверов при помощи некоего > универсального теста всегда наводила на иронию. Так оно и есть. Но это чем-то отдаленно напоминает спортивные соревнования. Вот посмотрел недавно прикольные соревнования по керлингу - это где булыжники по льду катают, модифицируя траекторию направленной зачисткой льда. Какова практическая применимость в реальной жизни таких навыков? А все-равно прикольно :)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: > И какой на него (тест) дал ссылку на sql.ru? Точно не я. Но то, что оно там всплывет и начнется подобный флейм - почему-то сразу предполагал. Сглазил, наверное :) > Чуствую пошлю всех в зад - как протестировал, так и протестировал. А что мешает? Каждый может повторить эти тесты у себя. Если захочет. > чего ещё хочет общественность мне не понятно? Очень даже понятно. Хочет (якобы)объективного (псевдо-)научного обоснования своих религиозных убеждений.
Re: оПЕДБЮПХРЕКЭМШЕ ПЕГСКЭРЮРШ ОН РЕЯРС TPCR (YA/FB/ORA/MS/PG)
Oleg LOA wrote: > чего ещё хочет общественность мне не понятно? Очевидно углублённого изучения > DB2 :-):-):-) Олежка, обчественность - она всегда чего-нить да хочет. Известно же, на три вещи можно смотреть бесконечно - на огонь, на текущую воду, и на то, как другой работает ;) -- Regards. Ded.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Alexander Goldun wrote: > Тоже позабавило. Хотел там на это ответить, да жаба задушила буквы > тратить :) Да, с буквами у меня в последнее время тоже напряжёнка. Так, когда башка окончательно охреневает, потрачу несколько десятков, и опять за своё :) -- Regards. Ded.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
А что означает замечание про PG: "80% ОЗУ не получил тока PG. Т.к. он на Win32 крутился по классической архитектуре - у него 20МБ было на кэш."? Он в принципе не мог взять больше 20мб или умышленно ограничил?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! You wrote on Wed, 1 Mar 2006 15:46:25 +0300: OL> Ты дальше читай, особенно про оптимизацию в DB2 OL> выборки первых N записей. Почитал. Флеймогоны. А ты им карикатуры на DB2 постить не пробовал? Джихад, наверное, развяжут... :) Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixtntobru
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA wrote: > Я как-то слабо себе представляю тиражируемый продукт с DB2 Express в том > виде в котором она есть сейчас - устанешь поддерживать пользователей. Вот бестолочь. Тебе же всё объяснили - а деньги получать каждый раз как юзер чихнёт за вытирание соплей? И админам, и продавцу прилады, и самим IBM ;) -- Regards. Ded.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: > Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в > классике. Удивило и разочаровало, однако. Я думал, там архитектура как в супере. http://sql.ru/forum/actualthread.aspx?tid=267757
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Alexander Goldun" wrote in message news:[EMAIL PROTECTED] > Oleg LOA пишет: > >> Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в >> классике. > > Удивило и разочаровало, однако. Я думал, там архитектура как в супере. > http://sql.ru/forum/actualthread.aspx?tid=267757 shared_buffers я куртил - разницы в быстродействии не заметил
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: >>> Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в >>> классике. >> Удивило и разочаровало, однако. Я думал, там архитектура как в супере. >> http://sql.ru/forum/actualthread.aspx?tid=267757 > shared_buffers я куртил - разницы в быстродействии не заметил М... да, однако. Гадание на кофейной гуще по поводу общего кэша в постгресе начинает там походить на пятничный юмор :)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Alexander Goldun" wrote in message news:[EMAIL PROTECTED] > Oleg LOA пишет: > >> Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в >> классике. > > Удивило и разочаровало, однако. Я думал, там архитектура как в супере. > http://sql.ru/forum/actualthread.aspx?tid=267757 shared_buffers я куртил - разницы в быстродействии не заметил
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Alexander Goldun" wrote in message news:[EMAIL PROTECTED] > Oleg LOA пишет: > М... да, однако. Гадание на кофейной гуще по поводу общего кэша в > постгресе начинает там походить на пятничный юмор :) Он там есть, только возможно простое кэширование винды применительно к тесту работает не хуже. У меня от был выставлен в 1.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Самое интересное с DB2 что проблема всё же проявилась: http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=266639&pg=6
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Oleg LOA" ... > Самое интересное с DB2 что проблема всё же проявилась: > http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=266639&pg=6 А не связаны ли наши с тобой разные рез-ты с большим кешем из-за того же HT ? У меня AMD... -- Хорсун Влад
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
"Vlad Horsun" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Oleg LOA" ... >> Самое интересное с DB2 что проблема всё же проявилась: >> http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=266639&pg=6 > >А не связаны ли наши с тобой разные рез-ты с большим кешем > из-за того же HT ? У меня AMD... Нет, у них в DB2 там полная жопа с определением CPUSPEED
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! You wrote on Wed, 15 Feb 2006 11:47:45 +0300: ??>> ??>> Ãà òû øòî? Ãòîáû õîðîøî ïîîáåäà òü ÃóæÃî Ãèêà ê ÃÃ¥ ìåÃüøå ñóòîê... Ãëåã, à ÃÃ¥ äóìà ë ïîïðîáîâà òü Ãà õà ëÿâÃîé DB2 ? Ãåñüìà ëþáîïûòñâåÃÃî áûëî áû óçÃà òü ðåçóëüòà òû With best regards, Sergey Nikolaenko. E-mail: serg (òóò ôèãÃÿ) armax.ru
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! Oleg LOA wrote: > X X X ÐÑевÑÑение 8-ми ÑаÑов, ÑÑÑное планиÑование ÐÐÐÐÐÐÐ !!! СеÑвеÑа Ñ > планом Ð¾Ñ YA/FB > P.S. ÐÐ»Ñ 15-го запÑÐ¾Ñ Ð½Ðµ Ñмог напиÑаÑÑ Ð¿Ð»Ð°Ð½, Ñо ÑолÑÐºÑ Ð½Ð¾Ð»Ñ,Ñо ÑеÑвак Ð¿Ð°Ð´Ð°ÐµÑ > :-(. ÑÑо-Ñо Ñ Ð¿ÐµÑеÑÑал понимаÑÑ, о каком ÑеÑÑе Ð²Ñ Ð³Ð¾Ð²Ð¾ÑиÑе. IB 7.5 не кÑÑÐ°ÐµÑ Ð¿Ð»Ð°Ð½Ñ Ð½Ð° 3-ем и 20-ом запÑоÑе. РеÑение ÑÑÑ http://ibdeveloper.com/tests/tpc-r/some-comments-on-query-n-3/ оÑкÑда Ñам пÑоблема Ñ 15-Ñм запÑоÑом? У ÐлекÑÐµÑ Ð¿Ð¾ ÑÑÐ¾Ð¼Ñ ÑеÑÑÑ Ð² 15-ом запÑоÑе Ð¿Ð»Ð°Ð½Ñ Ð¾Ð´Ð¸Ð½Ð°ÐºÐ¾Ð²Ñе: FB 1.5 10.83 "PLAN (SUPPLIER INDEX (SUPPLIER_PK)) PLAN SORT (SORT (JOIN (PART NATURAL,PARTSUPP INDEX (PARTSUPP_PK" IB 7.5.1 30.45 "PLAN (SUPPLIER INDEX (SUPPLIER_PK)) PLAN SORT (SORT (JOIN (PART NATURAL,PARTSUPP INDEX (PARTSUPP_PK" -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! Oleg LOA wrote: > X X X ÐÑевÑÑение 8-ми ÑаÑов, ÑÑÑное планиÑование ÐÐÐÐÐÐÐ !!! СеÑвеÑа Ñ > планом Ð¾Ñ YA/FB Ñ Ð¿Ð¾Ð½Ñл. ТеÑÑ ÐлекÑÐµÑ Ñ Ð¿ÑоÑедÑÑой. Ð Ñ ÑÐµÐ±Ñ - Ñ view. Ðлан полÑÑаеÑÑÑ Ñакой: PLAN SORT (MERGE (SORT (SUPPLIER ORDER RDB$PRIMARY2), SORT (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE) > P.S. ÐÐ»Ñ 15-го запÑÐ¾Ñ Ð½Ðµ Ñмог напиÑаÑÑ Ð¿Ð»Ð°Ð½, Ñо ÑолÑÐºÑ Ð½Ð¾Ð»Ñ,Ñо ÑеÑвак Ð¿Ð°Ð´Ð°ÐµÑ > :-(. Ñ Ð¿Ð¾Ð¿ÑобÑÑ... -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! Dmitri Kuzmenko wrote: > PLAN SORT (MERGE (SORT (SUPPLIER ORDER RDB$PRIMARY2), > SORT (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE) > >>P.S. ÐÐ»Ñ 15-го запÑÐ¾Ñ Ð½Ðµ Ñмог напиÑаÑÑ Ð¿Ð»Ð°Ð½, Ñо ÑолÑÐºÑ Ð½Ð¾Ð»Ñ,Ñо ÑеÑвак Ð¿Ð°Ð´Ð°ÐµÑ >>:-(. > > Ñ Ð¿Ð¾Ð¿ÑобÑÑ... Ð¿Ð¾Ð»Ð½Ð°Ñ Ð¶, ниÑего лÑÑÑе PLAN SORT (MERGE (SORT (SUPPLIER ORDER RDB$PRIMARY2),SORT (SORT (REVENUE0 LINEITEM NATURAL не полÑÑаеÑÑÑ. Ðдин Ñ Ñен, Ñ Ð´Ð°Ð¶Ðµ его пÑобоваÑÑ Ð½Ðµ бÑдÑ, поÑÐ¾Ð¼Ñ ÑÑо Ñ Ð¸Ð½Ð´ÐµÐºÑом из LINEITEM вÑе-Ñаки вÑбиÑалоÑÑ 225РзапиÑей из 6000Ð, Ñо еÑÑÑ Ð²Ñего 1/24-Ð°Ñ ÑаÑÑÑ. То еÑÑÑ, здеÑÑ Ð²Ð°ÑÐ¸Ð°Ð½Ñ Ñ view не пÑокаÑÑваеÑ. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! Oleg LOA wrote: > РезÑме? > > IB7 вообÑе не Ð¼Ð¾Ð¶ÐµÑ Ð²ÑполниÑÑ Ð·Ð°Ð¿ÑÐ¾Ñ 15 TPCR без ÑаÑкÑÑÑÐ¸Ñ ÐµÐ³Ð¾ в пÑоÑедÑÑÑ?! Ðлан IB 7.5.1: PLAN SORT (MERGE (SORT (SUPPLIER ORDER RDB$PRIMARY2), SORT (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE) план FB PLAN JOIN (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE)),SUPPLIER INDEX (SUPPLIER_PK)) Ñ ÑÑÑ Ð½Ðµ ÑовÑем понимаÑ, заÑем опÑимизаÑÐ¾Ñ IB пÑинÑлÑÑ Ð²Ñе ÑоÑÑиÑоваÑÑ Ð¸ÑполÑзÑÑ SUPPLIER ORDER вмеÑÑо индекÑного поиÑка и join. СооÑвеÑÑÑвенно, можно бÑло Ð±Ñ "пÑибиÑÑ Ð¿Ð»Ð°Ð½ гвоздиками", но Ñ Ð·Ð° вÑкÑÑÑивание индекÑов, а в данном ÑлÑÑае оно невозможно. ÐолÑÑе вÑего Ð¼ÐµÐ½Ñ Ð¿Ð¾ÑÑÑÑÐ°ÐµÑ (и пÑоблема дÑÐ¼Ð°Ñ Ð¸Ð¼ÐµÐ½Ð½Ð¾ ÑÑÑ) SORT (SUPPLIER ORDER RDB$PRIMARY2) как бÑ, ÐÐФÐÐÐ??? -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! Oleg LOA wrote: >>план FB >>PLAN JOIN (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE)),SUPPLIER INDEX >>(SUPPLIER_PK)) > > У ÑÐµÐ±Ñ Ð¾Ð½ Ð¿Ð°Ð´Ð°ÐµÑ Ð¸Ð»Ð¸ пеÑеваÑÐ¸Ð²Ð°ÐµÑ ÐµÐ³Ð¾? ÑÑпеÑ. С ÑÑим планом он Ð¿Ð°Ð´Ð°ÐµÑ Ð½Ð° Prepare. > Ðак Ð±Ñ Ð² коде-Ñо баÑдак полнÑй :-(, можно взÑÑÑ FB1.0 и пÑовеÑÐ¸Ñ Ð¿Ð»Ð°Ð½Ñ Ð½Ð° нÑм. погодиÑе... Ñ Ð¼ÐµÐ½Ñ ÐºÑивой запÑÐ¾Ñ Ð´Ð»Ñ FB бÑл, без order by s_suppkey. зÑÑ ÑÑ ÐµÐ³Ð¾ во view оÑоÑмил, мог Ð±Ñ Ð¸ Ñеликом оÑÑавиÑÑ :-) Так воÑ, IB 6.0.1.0 Ð´Ð°ÐµÑ Ð¿Ð»Ð°Ð½ PLAN MERGE (SORT (SUPPLIER ORDER SUPPLIER_PK),SORT (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE FB 1.0.3 Ð´Ð°ÐµÑ Ñакой же план. FB 1.5 Ð´Ð°ÐµÑ Ð¿Ð»Ð°Ð½ PLAN SORT (JOIN (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE)),SUPPLIER INDEX (SUPPLIER_PK))) IB 7.5 (и IB 7.1 SP2) Ð´Ð°ÐµÑ Ð¿Ð»Ð°Ð½ PLAN SORT (MERGE (SORT (SUPPLIER ORDER RDB$PRIMARY2),SORT (SORT (REVENUE0 LINEITEM INDEX (LINEITEM_SHIPDATE) Ð¿Ð°Ð´Ð°ÐµÑ Ð½Ð° плане Ð¾Ñ FB 1.5, коÑоÑÑй ÑÑÑ Ð¿Ñиведен вÑÑе. p.s. IB7.1 и 7.5 пÑовеÑÑл Ñакже и на базе Ð¾Ñ FB, ÑÑÐ¾Ð±Ñ Ð½Ðµ бÑло Ñомнений в ÑаÑÑ Ð¾Ð¶Ð´ÐµÐ½Ð¸Ð¸ ÐÐ. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! Oleg LOA wrote: > "Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >>погодиÑе... Ñ Ð¼ÐµÐ½Ñ ÐºÑивой запÑÐ¾Ñ Ð´Ð»Ñ FB бÑл, без order by s_suppkey. >>зÑÑ ÑÑ ÐµÐ³Ð¾ во view оÑоÑмил, мог Ð±Ñ Ð¸ Ñеликом оÑÑавиÑÑ :-) > > ÐÑо менÑÑ ÑÑÑÑ Ð´ÐµÐ»Ð°? ÐÑли да, Ñо заменÑ. да пÑоÑÑо Ð¼ÐµÐ½Ñ Copy/Paste заломало :-) > ÐÑоÑе мне нÑжно как-Ñо вÑполниÑÑ 15-й запÑÐ¾Ñ Ð½Ð° IB7 без пÑоÑедÑÑÑ, > и за вÑÐµÐ¼Ñ Ð¼ÐµÐ½ÑÑее Ñем Ð½ÐµÐ´ÐµÐ»Ñ :-). ÐÑÑÑ Ð²Ð°ÑианÑÑ?! боÑÑÑ ÑÑо неÑ. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Ðлег, Ðима, можеÑе ÑказаÑÑ Ð¿ÑиблизиÑелÑное вÑÐµÐ¼Ñ Ð¾ÑÑабоÑки 16-го запÑоÑа поÑле Ñого как опÑимизаÑоÑÑ Ð¸Ð½ÑÐµÐ»Ð»ÐµÐºÑ Ð¿Ð¾Ð´Ð¿Ñавили? Роман
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
> ÐоÑÑдок Ñакой же как Ñ Fb1.5/YA, ÑоÑно не Ð¿Ð¾Ð¼Ð½Ñ - ÑеÑÑ Ð¸ ÑезлÑÑÑаÑÑ Ð´Ð¾Ð¼Ð°. > > РпоÑÐµÐ¼Ñ Ñакой вопÑÐ¾Ñ Ð²Ð¾Ð·Ð½Ð¸Ðº? Я вÑÑлал Твои ÑезÑлÑÑаÑÑ ÐÐ¾Ð»Ñ Ð ÑзендалÑ, а он Ñказал ÑÑо Ð¼Ð¾Ð¶ÐµÑ Ð±ÑÐ´ÐµÑ Ð½Ð°Ð´Ð¾ во вÑÐµÐ¼Ñ ÑелеконÑеÑенÑии Ñ ÐºÐµÐ¼-Ñо из Forrester Research. Ðо как Ñ Ð¿Ð¾Ð½Ñл, он ÑÑо не иÑполÑзовал... Роман
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
> ÐÑли еÑÑÑ ÑпеÑÑ Ð¿Ð¾ ASA, Ñо ÑкажиÑе мне где мне подкÑÑÑиÑÑ ÑÑки, ÑÑо Ð±Ñ Ð¾Ð½ > update по болÑÑой ÑаблиÑÑ Ð½Ðµ делал мне неÑколÑко ÑÑÑок? Ðлег ÑвÑжиÑÑ Ñ Ð½ÐµÐºÐ¸Ð¼ ASCRUS на ÑоÑÑме SQL.RU - он модеÑаÑÐ¾Ñ Ð² ÑоÑÑме РабоÑа, Ñак ÑÑо найдеÑÑ ÑÑазÑ. Ðн вÑоде ÑÐ¿ÐµÑ Ð¿Ð¾ ASA.
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Oleg! Oleg LOA wrote: > "Roman Rokytskyy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >>>ÐоÑÑдок Ñакой же как Ñ Fb1.5/YA, ÑоÑно не Ð¿Ð¾Ð¼Ð½Ñ - ÑеÑÑ Ð¸ ÑезлÑÑÑаÑÑ Ð´Ð¾Ð¼Ð°. > > > ÐÑли еÑÑÑ ÑпеÑÑ Ð¿Ð¾ ASA, Ñо ÑкажиÑе мне где мне подкÑÑÑиÑÑ ÑÑки, на sql.ru еÑÑÑ ASCRUS, еÑли Ñ Ð½Ðµ оÑибÑÑ. ÐолÑÑой попÑлÑÑизаÑÐ¾Ñ ASA в ÑоÑÑме IB/FB/YA :-) -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
> ÐолÑÑе извеÑÑен как вÑдаÑÑийÑÑ Ð³Ð¾Ð½Ñик ;) ÐонÑик-не гонÑик, Ð°Ð±Ñ Ð¿Ð¾Ð´Ñказал ÑÑо нÑжно :-)
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Alex! Alex Cherednichenko wrote: > DK> на sql.ru еÑÑÑ ASCRUS, еÑли Ñ Ð½Ðµ оÑибÑÑ. > DK> ÐолÑÑой попÑлÑÑизаÑÐ¾Ñ ASA в ÑоÑÑме IB/FB/YA :-) > > ÐолÑÑе извеÑÑен как вÑдаÑÑийÑÑ Ð³Ð¾Ð½Ñик ;) пÑи вÑем ÑÑом он ASA оÑÐµÐ½Ñ Ð½ÐµÐ¿Ð»Ð¾Ñ Ð¾ знаеÑ. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Ðлег, > ÐÑли еÑÑÑ ÑпеÑÑ Ð¿Ð¾ ASA, Ñо ÑкажиÑе мне где мне подкÑÑÑиÑÑ ÑÑки, ÑÑо Ð±Ñ Ð¾Ð½ > update по болÑÑой ÑаблиÑÑ Ð½Ðµ делал мне неÑколÑко ÑÑÑок? Ð Ñо Ñ Ð½Ð¸ÐºÐ°Ðº не > Ð¼Ð¾Ð³Ñ Ð´Ð»Ñ Ð½ÐµÐ³Ð¾ подгоÑовиÑÑ Ð´Ð°Ð½Ð½Ñе TPCR. ÐаннÑе залил, Ñо нÑжно вÑполниÑÑ > паÑÑ update по вÑем ÑаблиÑам - Ñак Ð²Ð¾Ñ ÑоÑÐ¼Ð¾Ð·Ð¸Ñ Ð½ÐµÐ¼ÐµÑÑнно: ÑÑ Ð¾Ð´Ð¸Ñ Ð² IO и > вÑÑ. ÐÑли не Ñложно, пÑогони плиз ÑеÑÑÑ Ñ Ingress Ñоже. Ð Ñо, как мне кажеÑÑÑ, где-Ñо за пол-года его бÑдÑÑ Ð¾Ð¿ÑÑÑ ÑилÑно попÑлÑÑизиÑоваÑÑ, а он нам ÑеоÑеÑиÑеÑкий конкÑÑÐµÐ½Ñ Ð¿Ð¾ опенÑоÑÑÑ. ÐÑ Ð¸ еÑли бÑÑÑ ÑовÑем наглÑм - бÑло Ð±Ñ Ð¸Ð½ÑеÑеÑно поÑмоÑÑеÑÑ ÐµÑÑÑ Ð»Ð¸ ÑазлиÑÐ¸Ñ Ð¿Ð¾ бÑÑÑÑодейÑÑÐ²Ð¸Ñ Ñ ÑкÑпÑеÑÑ-веÑÑий ÐÑакла и MSSQL. Роман
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
> Ргде его взÑÑÑ Ð² ноÑмалÑном ваÑианÑе? гммм... они ÑÑо-Ñо Ñам пеÑеÑÑÑаиваÑÑ... еÑÑÑ ÑолÑко Ð´Ð»Ñ ÐинÑкÑа... Ð½Ñ Ð»Ð°Ð´Ð½Ð¾, "баба з воза, конÑм легÑе" :)) >> ÐÑ Ð¸ еÑли бÑÑÑ ÑовÑем наглÑм - бÑло Ð±Ñ Ð¸Ð½ÑеÑеÑно поÑмоÑÑеÑÑ ÐµÑÑÑ Ð»Ð¸ >> ÑазлиÑÐ¸Ñ Ð¿Ð¾ бÑÑÑÑодейÑÑÐ²Ð¸Ñ Ñ ÑкÑпÑеÑÑ-веÑÑий ÐÑакла и MSSQL. > > ТеÑÑÑ ora и mssql Ñже еÑÑÑ. То-еÑÑÑ, ÑледÑÐµÑ ÑÑиÑаÑÑ, ÑÑо ÑезÑлÑÑаÑÑ MSDE или MS SQL Server 2005 Express не бÑдÑÑ Ð¾ÑлиÑаÑÑÑ Ð¾Ñ Ð¿Ð¾Ð»Ð½Ð¾Ñенного ваÑианÑа? Ðли же Ñ Ð½Ðµ Ñак понÑл/пÑоÑиÑал надпиÑи и Ð¢Ñ ÑеÑÑиÑовал на ÑÑезанÑÑ Ð²ÐµÑÑиÑÑ ? Роман
Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)
Hello, Alexander! Alexander Goldun wrote: > ЧÑо вÑÐ´Ð°ÐµÑ SELECT @@version ? ASCRUS ÑÑвеÑждаеÑ, ÑÑо Ñам на ÑайÑе Ð»ÐµÐ¶Ð¸Ñ > ÑÑÑÐ°Ñ Ð²ÐµÑÑÐ¸Ñ 9.0.2, Ñ ÐºÐ¾ÑоÑой поломали опÑÐ¸Ð¼Ð°Ð¹Ð·ÐµÑ Ð¸ надо ÑÑавиÑÑ > поÑледний паÑÑ (ebf). У него Ñакой же Ð°Ð¿Ð´ÐµÐ¹Ñ 10-милионной ÑаблиÑÑ Ð¿ÑоÑел > за 400 Ñек. Ð´Ð»Ñ Ð·Ð°Ð¿ÑоÑа update lineitem set field = trim(field); imho опÑимизаÑÐ¾Ñ Ð½Ðµ Ð¸Ð¼ÐµÐµÑ Ð°Ð±ÑолÑÑно никакого знаÑениÑ. СÑÑаниÑа в 2кб вÑе-Ñаки маловаÑо, опÑималÑнее бÑÐ´ÐµÑ Ð½Ð°Ð²ÐµÑное > 8кб Ð´Ð»Ñ Ñакой базÑ. опÑималÑнее бÑÐ´ÐµÑ ÑÐ°Ð·Ð¼ÐµÑ ÑÑÑаниÑÑ, ÑквиваленÑнÑй Ð´Ð»Ñ Ð²ÑÐµÑ ÑеÑÑиÑÑемÑÑ Ð´Ð°Ð½Ð½Ñм ÑеÑÑом баз. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
