Hello, Dmitry! You wrote on Thu, 22 Jun 2006 16:52:29 +0400: [Sorry, skipped]
DY> Ладно, заменим слово "расчет" на "оценку" :-) DY> а) FB2 оценивает кол-во попаданий в BETWEEN как: <кол-во записей> * DY> <коэф>. б) вариант от критиков: <кол-во записей> * <селективность> / DY> <коэф>. DY> или другими словами: DY> а) в N раз меньше кол-ва записей в таблице DY> б) в N раз больше, чем вернет равенство по этому же столбцу DY> Чем второй вариант концептуально правильнее? Хотя бы уже тем, что использует статистику по индексу. Вариант а) фактически не использует индекс вообще. О чем я и писал ранее - смысл в индексе пропадает. Лично я за вариант б). О весовых коэффициентах можно спорить или не спорить. Или еще лучше - вынести их в конфигурациооный файл, как и выбор варианта а) или б) для работы. Это очень сложно сделать? По-моему, был бы самый оптимальный вариант. Причем рассказать, что нужно поставить, чтобы получить вариант оптимизатора для FB 1.5 или для FB 2.0 ??>> 454842 из общего количества 1003575, т.е. практически половина. Только ??>> при чем тут это? В сервере же нет гистограмм DY> Вот именно что нету. И оптимизатор верит статистике и считает этот DY> индекс хорошим. Как минимум лучше, чем по дате (с учетом BETWEEN). Т.е. DY> проблема на самом деле комплексная - сочетание более пессимистичной DY> политики оптимизатора и "перекошенного" поля DOCUMENT_ID. DY> Сравни время выполнения при DOCUMENT_ID = 1 (или что там более DY> уникально) с двумя планами: DY> - PLAN (D INDEX (FK_DOCS_FROM, DOCS_IDX_DATE)) DY> - PLAN (D INDEX (FK_DOCS_FROM, FK_DOCUMENT_ID)) Чуть позже сделаю. -- With best regards, Yuri Grabar. E-mail: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ -~----------~----~----~----~------~----~------~--~---
