Hello, Dmitry! You wrote on Thu, 22 Jun 2006 14:37:15 +0400: DY> "Boulitchev Aleksey" <[EMAIL PROTECTED]> wrote: > > неужели на это будет так DY> трудно уговорить? мы - Stella, Ltd - за DY> Т.е. ты еще по себе не примерял, но уже "за"? :-)
DY> Будь конструктивнее. Докажи, что для BETWEEN (ну или для STARTING - там DY> ситуация схожая) оценка выборки "в N раз больше, чем при равенстве" DY> правильнее, чем "одна M-я часть таблицы". Ну утерпел... :) Дим, давай только не будем передергивать. Изначально речь шла не "взять between перед равенством", а о том что из трех индексов, которые теоретически могли быть использованы, были взяты два - один, у которого селективность была самой высокой, и сам бог велел его использовать, и второй, у которого селективность была в 70 раз хуже, чем у третьего и только потому что для второго условие было на "=", а у третьего на "between". Далее выяснялось, что если отключить использование второго индекса при помощи +0, то третий вообще не будет использоваться. И все это всего-лишь потому, что для третьего индекса условие на between. И чего я сделал вывод, что построение индексов по полям, по которым в запросах бывает "за период" (т.е. between), в FB 2.0 теряет всякий смысл - они все равно никогда (ну или почти никогда) не будут использоваться). Городить же кучу составных индексов по возможным или часто используемым в запросах комбинациях как-то себе дороже будет... Проще остаться на FB 1.5. Напомню еще раз: > Запрос: > select count(*) > from DOCS > where DOC_DATE between ?DATE_FROM and ?DATE_TO > and FROM_ID = ?FROM_ID > and DOCUMENT_ID = 2 > > Селективности по индексам: > > по DOC_DATE - 0,00048169 > по FROM_ID - 0,00017614 > по DOCUMENT_ID - 0,03333333 > > план для запроса на FB 1.5.3 и на FB 2.0.12691 (на этой же базе, т.е. на > ODS > 10.1): > > PLAN (D INDEX (FK_DOCS_FROM, DOCS_IDX_DATE)) И также еще раз уточню, что к выбору оптимизатором индекса по FROM_ID (это тот, о котором ты мне писал про 170 часть при выборке), я никаких претензий не имею. Архиправильный выбор! Но вот использование индекса по DOCUMENT_ID вместо индекса по DOC_DATE как-то сильно-сильно нелогично. Даже если по конкретным значениям диапазона дат требовался бы перебор 50% данных они бы прекрасно отрезались при слиянии с индексом по FROM_ID. Фактически, получилось бы если и хуже, чем при использовании только одного индекса по FROM_ID, то не на много. А могло бы быть и лучше, в случае, если диапазон дат был бы задан маленький (на что собственно и рассчитывалось...). При сегодняшнем выборе получается, что лучше, чем по одному индексу по FROM_ID не будет в принципе при любом диапазоне дат. Только жуткие тормоза при слиянии с "плохим" индексом по DOCUMENT_ID. PS: Все, умолкаю... -- With best regards, Yuri Grabar. --~--~---------~--~----~------------~-------~--~----~ -~----------~----~----~----~------~----~------~--~---
