Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Vlad Horsun]

"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)

[Oleg LOA]

Самое интересное с DB2 что проблема всё же проявилась:
http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=266639&pg=6

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"Alexander Goldun"  wrote in 
message news:[EMAIL PROTECTED]
> Oleg LOA пишет:
> М... да, однако. Гадание на кофейной гуще по поводу общего кэша в
> постгресе начинает там походить на пятничный юмор :)

Он там есть, только возможно простое кэширование винды применительно к тесту 
работает не хуже. У меня от был выставлен в 1.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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]

Oleg LOA пишет:

>>> Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в 
>>> классике. 
>> Удивило и разочаровало, однако. Я думал, там архитектура как в супере.
>> http://sql.ru/forum/actualthread.aspx?tid=267757
> shared_buffers я куртил - разницы в быстродействии не заметил

М... да, однако. Гадание на кофейной гуще по поводу общего кэша в
постгресе начинает там походить на пятничный юмор :)

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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]

Oleg LOA пишет:

> Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в 
> классике. 

Удивило и разочаровало, однако. Я думал, там архитектура как в супере.
http://sql.ru/forum/actualthread.aspx?tid=267757

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Ded]

Oleg LOA wrote:

>   Я как-то слабо себе представляю тиражируемый продукт с DB2 Express в том 
> виде в котором она есть сейчас - устанешь поддерживать пользователей.

Вот бестолочь. Тебе же всё объяснили - а деньги получать каждый раз 
как юзер чихнёт за вытирание соплей? И админам, и продавцу прилады, и 
самим IBM ;)

-- 
Regards. Ded.

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Dmitri Kuzmenko]

Hello, Oleg!

Oleg LOA wrote:

> Да ну нафиг, вылезли на рынок обычных пользователей так пускай доделывают. 
> Ибо ситуация когда нужно досконально знать ситсему чтобы просто её водрузить 
 > на обычную машину явно не подходит для сектора рынка на которую нацелена DB2 
 > Express.

как я понимаю, пока они отмазываются возможностью поставлять свой собственный
конфиг при распространении DB2 Express.

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander A. Venikov]

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)

[Alexander Goldun]

А что означает замечание про PG: "80% ОЗУ не получил тока PG. Т.к. он на 
Win32 крутился по классической архитектуре - у него 20МБ было на кэш."?
Он в принципе не мог взять больше 20мб или умышленно ограничил?

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Dmitri Kuzmenko]

Hello, Alexander!

Alexander Goldun wrote:

> Так оно и есть. Но это чем-то отдаленно напоминает спортивные
> соревнования. Вот посмотрел недавно прикольные соревнования по керлингу
> - это где булыжники по льду катают, модифицируя траекторию направленной
> зачисткой льда. Какова практическая применимость в реальной жизни таких
> навыков? А все-равно прикольно :)

я играл в керлинг. правда, 1 раз, но долго. на халяву.
Очень даже ничего, можно в центр на Домодедовской сходить,
но надо толпой из 6 человек, или минимум 4 (это тяжелее, чем 6),
причем без глинтвейна есть риск замерзнуть :-)

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Ded]

Alexander Goldun wrote:

> Тоже позабавило. Хотел там на это ответить, да жаба задушила буквы
> тратить :)

   Да, с буквами у меня в последнее время тоже напряжёнка. Так, когда 
башка окончательно охреневает, потрачу несколько десятков, и опять за 
своё :)

-- 
Regards. Ded.

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Dmitri Kuzmenko]

Hello, Ded!
Ded wrote:

> универсального теста всегда наводила на иронию. Тест как сборник 
> запросов, отражающих те или иные потребности реальных задач, безусловно 
> полезен. Для выявления _у себя_ узких мест и последующей работы над 
> ними. 

дык. тест затем и был. на себя посмотреть. Ну и на других
посмотреть, с точки зрения "дефолта". Имеет смысл с них брать
пример, или нет. Мы же вряд ли (в ближайшем) будем внедрять возможность
указания размера экстента для таблиц или индексов, и другие
подобные "прибамбасы тонкого кручения".

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34

Re: оПЕДБЮПХРЕКЭМШЕ ПЕГСКЭРЮРШ ОН РЕЯРС TPCR (YA/FB/ORA/MS/PG)

[Ded]

Oleg LOA wrote:

> чего ещё хочет общественность мне не понятно? Очевидно углублённого изучения 
> DB2 :-):-):-)

Олежка, обчественность - она всегда чего-нить да хочет. Известно же, 
на три вещи можно смотреть бесконечно - на огонь, на текущую воду, и на 
то, как другой работает ;)

-- 
Regards. Ded.

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Dmitri Kuzmenko]

Hello, Oleg!

Oleg LOA wrote:

> Ты дальше читай, особенно про оптимизацию в DB2 выборки первых N записей.

да, это было супер. я тоже не понимаю, к чему там эти хинты.
правда, не понимаю, что там может быть за оптимизация,
если иметь в виду first только для запросов с сортировками.

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

Oleg LOA пишет:

> И какой  на него (тест) дал ссылку на sql.ru? 

Точно не я. Но то, что оно там всплывет и начнется подобный флейм -
почему-то сразу предполагал. Сглазил, наверное :)

> Чуствую пошлю всех в зад - как протестировал, так и протестировал. 

А что мешает? Каждый может повторить эти тесты у себя. Если захочет.

> чего ещё хочет общественность мне не понятно? 

Очень даже понятно. Хочет (якобы)объективного (псевдо-)научного
обоснования своих религиозных убеждений.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

Ded пишет:

> Не менее забавна поза насчёт штрейкбрейхества "ребят из Firebird", 
> отбивающих хлеб у админов всяких монстров :) 

Тоже позабавило. Хотел там на это ответить, да жаба задушила буквы
тратить :)

+1, как говорят на auto.ru :)


> А вообще-то меня идея сравнения серверов при помощи некоего 
> универсального теста всегда наводила на иронию. 

Так оно и есть. Но это чем-то отдаленно напоминает спортивные
соревнования. Вот посмотрел недавно прикольные соревнования по керлингу
- это где булыжники по льду катают, модифицируя траекторию направленной
зачисткой льда. Какова практическая применимость в реальной жизни таких
навыков? А все-равно прикольно :)

Re: оПЕДБЮПХРЕКЭМШЕ ПЕГСКЭРЮРШ ОН РЕЯРС TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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]

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)

[Karabas Barabas]

Hello, Oleg!
You wrote  on Wed, 1 Mar 2006 15:46:25 +0300:

 OL> Ты дальше читай, особенно про оптимизацию в DB2 выборки первых N
 OL> записей.

Прочитал, логика там странная, впечатление такое, что название хинта не 
соответствует его функции

-

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Karabas Barabas]

Hello, Oleg!
You wrote  on Wed, 1 Mar 2006 15:32:59 +0300:

 OL> Вот уже фаны DB2 налетели. Ну не нравится им результат 2-го запроса и
 OL> всё тут.

 OL> http://www.sql.ru/forum/actualthread.aspx?tid=266639&pg=-1

улыбнуло: "Что-то я там увидел тока новый начинающий какой-то форум по БД. 
Значительно уступающий данному. Таких "тестов" наверняка полно и здесь"

-

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

Вот уже фаны DB2 налетели. Ну не нравится им результат 2-го запроса и всё тут.

http://www.sql.ru/forum/actualthread.aspx?tid=266639&pg=-1

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Dmitri Kuzmenko]

Hello, Oleg!

Oleg LOA wrote:

> Мы где-то 1.7 - 2 GB, ASA столько же. ORA/MS./PG от 4 до 6 GB.

а db2?


-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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]

Hello, Oleg!

интересуют также конечные размеры БД (м.б. плюс лог) после заливки
данных в БД.

а также перечень параметров конкретных серверов, что было изменено
в отношении значений по умолчанию (например для ASA?).

-- 
Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

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)

[Oleg LOA]

Добавил результаты ASA9, цифры говорят сами за себя.


По поводу косяка с массовым обновлением lineitem на ASA9 - виноваты индексмы. 
Т.е. это явные грабле в ASA. Тотже Ya отработал запрос за пару минут, MS 
копался раздувая лог 1 час, ORA выполнил быстрее

На этом тестирование заканчиваю. Положительный эффект есть - пару косяков в FB2 
подправили.



log.rar
Description: Binary data

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

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)

[Alexander Goldun]

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]

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]

"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)

[Alexander Goldun]

Dmitri Kuzmenko пишет:
> для запроса
> update lineitem set field = trim(field);
> 
> imho оптимизатор не имеет абсолютно никакого значения.

Да, неактуален. Не знаю точный номер версии у Олега, но существенные
"поломки" в 9.0.2 в начальных выпусках были - тогда достаточно много
изменений вносилось. Почему они именно его выложили на сайт, не
потрудившись хотя бы упомянуть про апгрейды - без понятия.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

Так и не скомпилял я этот 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]

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

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg Deribas]

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)

[Alexander Goldun]

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)

[Roman Rokytskyy]

 > И где его взять в нормальном варианте?

гммм... они что-то там перестраивают... есть только для Линукса... ну ладно, 
"баба з воза, коням легше" :))

 >> Ну и если быть совсем наглым - было бы интересно посмотреть есть ли
 >> различия по быстродействию у экспресс-версий Оракла и MSSQL.
 >
 > Тесты ora и mssql уже есть.

То-есть, следует считать, что результаты MSDE или MS SQL Server 2005 Express 
не будут отличатся от полноценного варианта? Или же я не так понял/прочитал 
надписи и Ты тестировал на урезаных версиях?

Роман 

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"Alexander Goldun"  wrote in 
message news:[EMAIL PROTECTED]
> Oleg LOA пишет:
> 
>> я конечно понимаю праздники...но подозревать меня в отсутствии PK в 
>> таблице?

pk есть, твои рекомендации с добавлением страниц сделал - толку ноль. IO идт 
постарничный с фалом БД

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"Roman Rokytskyy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Олег,
> Если не сложно, прогони плиз тесты с Ingress тоже. А то, как мне кажется, 
> где-то за пол-года его будут опять сильно популяризировать, а он нам 
> теоретический конкурент по опенсорсу.

И где его взять в нормальном варианте?

> Ну и если быть совсем наглым - было бы интересно посмотреть есть ли различия 
> по быстродействию у экспресс-версий Оракла и MSSQL.

Тесты ora и mssql уже есть.

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Roman Rokytskyy]

Олег,

 > Если есть спецы по ASA, то скажите мне где мне подкрутить руки, что бы он
 > update по большой таблицы не делал мне несколько суток? А то я никак не
 > могу для него подготовить данные TPCR. Данные залил, то нужно выполнить
 > пару update по всем таблицам - так вот тормозит немерянно: уходит в IO и
 > всё.

Если не сложно, прогони плиз тесты с Ingress тоже. А то, как мне кажется, 
где-то за пол-года его будут опять сильно популяризировать, а он нам 
теоретический конкурент по опенсорсу.

Ну и если быть совсем наглым - было бы интересно посмотреть есть ли различия 
по быстродействию у экспресс-версий Оракла и MSSQL.

Роман 

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

Oleg LOA пишет:

> я конечно понимаю праздники...но подозревать меня в отсутствии PK в 
> таблице?

Я не подозреваю, я высказываю гипотезу :) Ибо странно сие, а с подобным
проявлением уже сталкивался именно по причине отсутствия PK.

Мне аж самому интересно стало несмотря не некоторый цейтнот. Нашел уже
структуру данных TPCR. Но сейчас нечем скомпилять их заполнялку.

P.S. А ASCRUS что-то не откликается. Вот он любит подобные тесты :)

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

Oleg LOA пишет:

>> Большой популяризатор ASA в форуме IB/FB/YA :-)
> 
> Читал пейджер, популяризации аргументированной не обнаружил. 
> Пошёл углублённо читать документацию, однако обидно что с настройками 
> по умолчанию такие косяки :-(

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

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alex Cherednichenko]

Привет, Alexander!
Вы пишешь  26 февраля 2006:

 AG> Не считая себя профаном в ASA, смею заверить...

И шо, и справка имеется? (С)

--
With best regards, Alex Cherednichenko.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

Alex Cherednichenko пишет:
>>> Больше известен как выдающийся гонщик ;)
>> при всем этом он ASA очень неплохо знает.
> Насколько мы (профаны в оном), можем судить...

Не считая себя профаном в ASA, смею заверить, что ASCRUS действительно
очень хорошо в нем разбирается.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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]

Привет, Dmitri!
Вы пишешь  26 февраля 2006:

 >> Больше известен как выдающийся гонщик ;)

 DK> при всем этом он ASA очень неплохо знает.

Насколько мы (профаны в оном), можем судить...


--
With best regards, Alex Cherednichenko.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

Oleg LOA пишет:

> Если есть спецы по ASA, то скажите мне где мне подкрутить руки, 
> что бы он update по большой таблицы не делал мне несколько суток?

Я может мог бы чем-то помочь, но нужно видеть метаданные, запросы,
параметры запуска сервера и т.п.
почта alexgold эт inbox точка ru
аська 284122821

P.S. у базы есть transaction log или сделал без него?

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Dmitri Kuzmenko]

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)

[Kull Damned]

> Больше известен как выдающийся гонщик ;)
Гонщик-не гонщик, абы подсказал что нужно :-)

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alex Cherednichenko]

Привет, Dmitri!
Вы пишешь  26 февраля 2006:

 DK> на sql.ru есть ASCRUS, если я не ошибся.
 DK> Большой популяризатор ASA в форуме IB/FB/YA :-)

Больше известен как выдающийся гонщик ;)

--
With best regards, Alex Cherednichenko.

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Dmitri Kuzmenko]

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)

[Kull Damned]

> Если есть спецы по ASA, то скажите мне где мне подкрутить руки, что бы он 
> update по большой таблицы не делал мне несколько суток?
Олег свяжись с неким ASCRUS на форуме SQL.RU - он модератор в форуме Работа, 
так что найдешь сразу. Он вроде спец по ASA.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Roman Rokytskyy]

> Порядок такой же как у Fb1.5/YA, точно не помню - тест и резлуьтаты дома.
>
> А почему такой вопрос возник?

Я выслал Твои результаты Полю Рузендалю, а он сказал что может будет надо во 
время телеконференции с кем-то из Forrester Research. Но как я понял, он это 
не использовал...

Роман 

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Dmitry Yemanov]

"Roman Rokytskyy" 
<[EMAIL PROTECTED]> wrote:
>
> можете сказать приблизительное время отработки 16-го запроса после того 
> как оптимизатору интеллект подправили?

Точные цифры у Олега, я тест целиком не гонял. Должно быть 4-4.5 сек на кеше 
в 10К страниц.


--
Дмитрий Еманов

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Roman Rokytskyy]

Олег, Дима,

можете сказать приблизительное время отработки 16-го запроса после того как 
оптимизатору интеллект подправили?

Роман 

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Dmitry Yemanov]

"Oleg LOA" <[EMAIL PROTECTED]> wrote:
>
> Косяки с группировкой? Я прав?

Косяком бы я это не назвал. Код правильный, просто для aggregate поверх view 
он по определению работать не может :-)


--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> "Dmitry Yemanov" <[EMAIL PROTECTED]> 
> wrote:
>>
> подзапросах. Есть одна маленькая разница между обработкой чистого RSE и 
> вьюхи и она портит всю кашу. Диагноз мне ясен, но красивого решения пока 
> нет. Но наш "Варяг" так просто не сдается :-)

Косяки с группировкой? Я прав?

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Dmitry Yemanov]

"Dmitry Yemanov" <[EMAIL PROTECTED]> 
wrote:
>
> Разбираюсь.

В общем, там две проблемы с определением инвариантности подзапросов. 
Первая - логика не для всех видов подзапросов работает. Это я вроде 
исправил. Теперь, если тело "revenue" подставить в виде derived table, то 
15-й запрос летает. Однако, оригинальный вариант не работает из-за второй 
траблы - инвариантность спотыкается на сочетании агрегатов и вьюх в 
подзапросах. Есть одна маленькая разница между обработкой чистого RSE и 
вьюхи и она портит всю кашу. Диагноз мне ясен, но красивого решения пока 
нет. Но наш "Варяг" так просто не сдается :-)


--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

Добавил DB2

2 DY - последняя собрка нормально not in отрабатывает. Осталось решить проблему 
с оригинальным 15 запросом.


log.rar
Description: Binary data

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Alexander Goldun]

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)

[Alex Cherednichenko]

Привет, Dmitry!
Вы пишешь  16 февраля 2006:

 DY> ???- :-) ? ?  ?, ??? ??? ?. ? ??? 
? 

Фсё!
Теперь и спички кончились.
В темноте одиноко белеет чернотой вопросительный знак...

--
With best regards, Alex Cherednichenko.

Re: ??????????????? ?????????? ?? ????? TPCR (YA/FB/ORA/MS/PG)

[Dmitry Yemanov]

"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)

[Horsun Vlad]

"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)

[Dmitry Yemanov]

"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)

[Dmitri Kuzmenko]

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)

[Dmitri Kuzmenko]

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)

[Dmitri Kuzmenko]

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)

[Dmitry Yemanov]

"Oleg LOA" <[EMAIL PROTECTED]> wrote:
>
> может при сортировках винда вытестняет

У тебя в табличке первый запрос выполняется либо так же на 100К (1.5), либо 
чуток тормозит (2.0). А третий запрос на 100К выполняется значительно 
медленнее. Однако, размер сортировки у первого на три порядка больше, чем у 
третьего. Так что думаю, что сортировку стоит исключить из рассмотрения.


--
Дмитрий Еманов

Re: ��������������� ���������� �� ����� TPCR (YA/FB/ORA/MS/PG)

[Dmitri Kuzmenko]

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)

[Oleg LOA]

"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)

[Dmitry Yemanov]

"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)

[Oleg LOA]

"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)

[Dmitri Kuzmenko]

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)

[Oleg LOA]

"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)

[Oleg LOA]

"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)

[Dmitri Kuzmenko]

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)

[Dmitry Yemanov]

"Oleg LOA" <[EMAIL PROTECTED]> wrote:
>
> Результаты IB7

Олег, прогони при возможности сегодняшний снапшот 2.0 (с исправленным 16-м 
запросом) с кешем в 10К буферов, плиз. С кешем будем отдельно разбираться, 
но меня пока оптимизатор интересует.


--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Horsun Vlad]

"Oleg LOA" ...
> "Dmitry Yemanov" ...
> > "Oleg LOA" wrote:
> >>
> >> Ты мне скажи почему 14-й при смене размера кэша стал тормозить?
>
> Результаты IB7
...
>
>   3.2 ГГц/ 2 Гб

А каши ты ему сколько дал ?

-- 
Хорсун Влад

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Dmitry Yemanov]

"Oleg LOA" <[EMAIL PROTECTED]> wrote:
>
> Ты мне скажи почему 14-й при смене размера кэша стал тормозить?

Поигрался щаз немного с кешем. Вывод: тормоза начинаются при конкуренции 
кеша FB с кешем виндов за ОЗУ. Т.е. стоит поставить кеш FB ближе к размеру 
доступной памяти, как сразу наблюдаются жуткие тормоза. Ставим 
NO_BUFFERING - тормоза исчезают.

Впрочем, это никак не объясняет ситуацию с Дятлом :-) Ради интереса 
просмотрел diff для твоих cch.c и dpm.c - никаких функциональных отличий от 
FB2 не нашел.


--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Horsun Vlad]

"Dmitry Yemanov" ...
>
> "Dmitry Yemanov" > wrote:
> >
> > А вот с 16-м причина понятна - я отключил использование индексов для NOT
> > IN, в результате чего коррелированный подзапрос пошел натуралом. Следствие
> > налицо. Сейчас буду думать, что с этим делать.
>
> Вроде заборол. Теперь NOT IN с индексами должен корректно работать. И
> быстро, вдобавок :-)

Ну вот - хоть кто-то что-то делает ;)

-- 
Хорсун Влад

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Dmitry Yemanov]

"Dmitry Yemanov" <[EMAIL PROTECTED]> 
wrote:


А вот с 16-м причина понятна - я отключил использование индексов для NOT 
IN, в результате чего коррелированный подзапрос пошел натуралом. Следствие 
налицо. Сейчас буду думать, что с этим делать.


Вроде заборол. Теперь NOT IN с индексами должен корректно работать. И 
быстро, вдобавок :-)



--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Boris Loboda]

> 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)

[Horsun Vlad]

"Oleg LOA" ...

> С кэшем как я понял предложено мне разбираться? Типа сам нашёл - сам и
разбирайся :-):-):-),

Ну, если ты это уже когда-то правил, то тебе и карты в руки ;)

Но я всё-таки не верю, что это код кеша виноват, сорри...
Наш IO, конечно, далеко не оптимален и не умён, но тормозов
от р-ра кеша я не вижу. Хотя очень хотел бы увидеть - это дало
бы шанс повысить скорость до существенной переделки IO ;)


> у Влада как я понял замедление не наблюдается.

Это такой комплимент ? Спасибо :-)

-- 
Хорсун Влад

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[sasha]

http://www-306.ibm.com/software/data/db2/udb/db2express/download.html

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Dmitry Yemanov]

"Oleg LOA" <[EMAIL PROTECTED]> wrote:


Ты мне скажи почему 14-й при смене размера кэша стал тормозить?


Пока не скажу. Не все сразу :-)


Или у тебя там в оптимизаторе это учитывается?


Никак нет.


--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Sergey Nikolaenko]

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)

[Dmitry Yemanov]

"Oleg LOA" <[EMAIL PROTECTED]> wrote:


С кэшем как я понял предложено мне разбираться?


Заметьте, не я это предложил (с) :-)))


у Влада как я понял замедление не наблюдается.


Я еще у себя попробую. Не не сегодня.


--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> 
> "Oleg LOA"  wrote:
>>
>> Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-)
> 
> Оптимизатор уже в работе. У меня 14 и 16 запросы в блокнотике давно 

С кэшем как я понял предложено мне разбираться? Типа сам нашёл - сам и 
разбирайся :-):-):-), у Влада как я понял замедление не наблюдается.

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Dmitry Yemanov]

"Oleg LOA" <[EMAIL PROTECTED]> wrote:


Фиксаем оптимизатор, разбираемся с увеличинным кэшем и тоды да :-)


Оптимизатор уже в работе. У меня 14 и 16 запросы в блокнотике давно 
записаны, но все руки не доходили. Я на TPC-R каждое изменение оптимизатора 
тестирую :-)



--
Дмитрий Еманов

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[sasha]

Что значит где? Там всен страницы нормально подписаны.


Я так понимаю что сравнивались FB1.5.3 и PG 8.1.2, так?

Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)

[Oleg LOA]

"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)

[Boris Loboda]

> 2) Слухи о тормознутости PG сильно приувеличины :-)

Явно слухи, по  крайней мере экстракт метаданных на нем проходит в несколько 
раз быстрее чем на других серверах, а про остальное я не в курсе. :-)