Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Ого, спасибо, проверим :) Т.к. снапшоты еще не ожили, то могу собрать вам 2.1 или 2.5 с фиксом и выслать. Дай знать, если интересно. Но хотелось бы проверить фикс именно на оригинальной базе, а не на твоей тестовой. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Конечно интересно, проверим на оригинальной. Отлично. Если не очень сложно, то лучше 2.1. Супер или классик? Проверить только тот конкретный запрос, или еще на что-то обратить внимание? Как минимум тот запрос. Но лучше погонять этот билд и на других запросах - в целом лучше станет или хуже. Я думаю, у них не одна претензия была. Да и проверить, чтобы остальное не отвалилось :-) -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Попытался повторить это на тестовой БД - с трудом, но вроде получилось. http://rapidshare.com/files/144380650/TEST.rar.html 30МБ В общем, фикс у меня есть. На днях его оттестирую и (надеюсь) закоммичу. Если к понедельнику снапшоты оживут, то можно будет проверить на оригинальной не твоей базе :-) -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Это будет только в 2.5 или в 2.1.? тоже может попасть? Везде попадет. Но мне было бы удобнее, если бы вы сначала проверили на 2.5 (можно без бекап/рестора) и только потом (если все нормально) я бы перенес фикс в 2.0/2.1. Чтобы, если что не так, свои ошибки не плодить по всем бранчам :-) -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: В частном случае, поменялся порядок таблиц - натуралом сервер стал идти по самой большой. Статистика по индексам свежая? Из изменений, который могли повлиять я увидел только посегментную статистику. Начиная с 2.0 оптимизатор вообще наполовину переделан. Ну а кол-во строк в таблице он не оценивает, та ведь? Оценивает. TABLE_BIG = 2млн (PSG) TABLE_SMALL = 2тыс (SA) TABLE_MEDIUM = 20тыс (PG) FB 1.5 plan join (sa natural, pg index (table_big_idx1), psg index (pk_table_medium)) В плане индексы не соответствуют таблицам. FB 2.1.1 (с последней одс, после рестора) plan join (psg natural, pg index (table_big_idx3), sa index (table_small_org_idx)) Аналогично. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Сорри, опечатался. TABLE_BIG = 2млн (PG) TABLE_SMALL = 2тыс (SA) TABLE_MEDIUM = 20тыс (PSG) Я бы хотел взглянуть на эту базу. Ибо 2.1 не должен был выбрать такой плохой план. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Hello, Nikolay! Nikolay Ponomarenko wrote: Ну а кол-во строк в таблице он не оценивает, та ведь? оценивает. по размеру записи в rdb$formats и по количеству pointer page. т.е. количество записей в данном случае это вообще все версии, плюс фрагментированные страницы, и т.д. Собсно вопрос - предположения правильны и выхода как кроме +0(вроде как там запросов у них много) нет? вообще по идее идти натуралом по самой большой и жирной таблице - оптимальнее всего, если на нее ссылаются индексы с плохой селективностью. кстати, где расклад по времени, что такая выборка тормознее? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Оригинальная бд не моя, и весит 30гиг... Архив бекапа небось пару гиг всего :-) Попытался повторить это на тестовой БД - с трудом, но вроде получилось. http://rapidshare.com/files/144380650/TEST.rar.html 30МБ ОК, посмотрю сегодня. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Hello, Nikolay! Nikolay Ponomarenko wrote: DK кстати, где расклад по времени, что такая выборка тормознее? Тормознее, т.к. маленькая таблица, когда была основной, очень урезала выборку. Но относится ли этот случай к тем, которые должен разрулить оптмизатор в нынешнем виде - хз. ыыы. Где. Приведен. Пример. Времени. Выполнения. Первого. И. Второго. Запроса. ? :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: И все же хочется узнать точно, разве в запросах вида select * from table1 t1 join table2 t2 on t2.id=t1.id where t1.f1=15 условие where t1.f1=15 не вносится внутрь ДО выполнения джойна? Вносится. Первоисточник гласит что все же вносится. После него я собсно и стал выносить лишнее в where, в целях удобочитаемости запросов. И правильно делаешь. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Тормознее, т.к. маленькая таблица, когда была основной, очень урезала выборку. Но относится ли этот случай к тем, которые должен разрулить оптмизатор в нынешнем виде - хз. Не относится, увы. -- Дмитрий Еманов
Re: Вопрос по изменению оптимизатора с 1.5 по 2.1
Nikolay Ponomarenko wrote: Только я вот чесс гря не понимаю, на что может опираться оптимизатор, выбирая иной план. Ну разве что на размер таблицы? Размер считается в обоих версиях приблизительно одинаково. В данном случае разница лишь в посегментном учете селективности. Ведь если судить по качеству индексов, то он берет, в принципе, оптимальный вариант. И в полуторке оно работало неверно, используя только информацияю о хорошей селективности композита? Именно так. И на (в принципе худший) вариант наложилось наличие фильтра по малой таблице, который наверняка и дал ускорение. Надо бы какую-то эвристику ввести для неиндексированных предикатов, тогда результат мог бы быть более предсказуемым. Она как бы есть, но сильно зачаточная :-) Подумаю над этим. -- Дмитрий Еманов
