"Yuri Grabar" <[EMAIL PROTECTED]> wrote: > > Ты вроде как писал, что нет вообще никакого расчета - _всегда_ > используется > селективность 0.2
Ладно, заменим слово "расчет" на "оценку" :-) а) FB2 оценивает кол-во попаданий в BETWEEN как: <кол-во записей> * <коэф>. б) вариант от критиков: <кол-во записей> * <селективность> / <коэф>. или другими словами: а) в N раз меньше кол-ва записей в таблице б) в N раз больше, чем вернет равенство по этому же столбцу Чем второй вариант концептуально правильнее? > 454842 из общего количества 1003575, т.е. практически половина. Только при > чем тут это? В сервере же нет гистограмм Вот именно что нету. И оптимизатор верит статистике и считает этот индекс хорошим. Как минимум лучше, чем по дате (с учетом BETWEEN). Т.е. проблема на самом деле комплексная - сочетание более пессимистичной политики оптимизатора и "перекошенного" поля DOCUMENT_ID. Сравни время выполнения при DOCUMENT_ID = 1 (или что там более уникально) с двумя планами: - PLAN (D INDEX (FK_DOCS_FROM, DOCS_IDX_DATE)) - PLAN (D INDEX (FK_DOCS_FROM, FK_DOCUMENT_ID)) Будет ли второй вариант медленнее? -- Дмитрий Еманов --~--~---------~--~----~------------~-------~--~----~ -~----------~----~----~----~------~----~------~--~---
