|
|
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
сервер LI-V6.3.3.26655 Firebird 2.5 клиент 2.5.1.26351 IBExpert Есть таблица (лишние поля убрал) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Запрос Код: sql 1. 2. 3. 4. показывает план PLAN (ACCOUNT_STATE INDEX (ACCOUNT_STATE_ACC_ED_DESC)) что для меня несколько неожиданно ибо я ожидал PLAN (ACCOUNT_STATE INDEX (ACCOUNT_STATE_ACC_ED_DESC, ACCOUNT_STATE_ACC_ED_DESC)) Хочется узнать почему мои ожидания не оправдались. (И небольшое уточнение вопрос не про обходные пути) зы. записей в таблице 268773 Статистика для обоих индексов 0,000003720611..... Если нужна еще какая либо информация с удовольствием предоствлю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:11:19 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, на другой версии было иначе? m7m Код: sql 1. М? Так, теоретизирую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:15:24 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, 1. (Enddate = :Idate1 or Enddate = :Idate2) вырубает использование индекса (если бы он был только по Enddate) 2. Даже если бы там не было выражения, то с чего ты решил что индекс должен задействоваться дважды? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:18:29 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денис> 1. (Enddate = :Idate1 or Enddate = :Idate2) вырубает Симонов Денис> использование индекса (если бы он был только по Enddate) Ну здрасьте, приехали... Ты чего? :) Если сложный предикат, а индекс составной - да, наверное, возможны нюансы, но не в таком простом кейсе. P.S. Топик не читал. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:21:50 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
wadmanm7m, на другой версии было иначе? Именно этот запрос - без понятия, у меня к сожалению сейчас нет возможности проверить на другой версии Однако аналогичный запрос на другой таблице (только индекс там трех сегментный) работает ожидаемо для меня (т.е. в плане дважды упоминается индекс) wadmanm7m Код: sql 1. М? Так, теоретизирую. нет, никакие манипуляции с индексом, (asc, desc, добавление нового сегмента) не привели к ожидаемым мною результатам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:23:15 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
По сабжу - на первое поле индекса нет никаких доп.ограничений, уникальности? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:23:56 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, тьфу блин. Перепутал с другим случаем когда field = :param1 or param1 is null. Думаю что в этом случае оптимизатор решил что выгодней использовать только часть составного индекса. Тут для отвта нужны сведения по селективности отдельных сегментов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:25:45 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7mЕсли нужна еще какая либо информация с удовольствием предоставлю план на 2.5.2 не помешает. И на 2.5.0 заодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:28:35 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7mСтатистика для обоих индексов 0,000003720611..... ты забыл, что 2.5 анализирует селективность по всем сегментам композитного индекса, которая может быть хуже, чем суммарная селективность композита. Раньше композиты были вредны именно этим. Возможно, что по второму сегменту селективность плохая, и поэтому оптимизатор решил не париться, два раза сканируя весь индекс, а потом объединяя битмапы по OR, а просто отобрать записи по первому сегменту, причем один раз. В принципе, я бы и от предыдущих оптимизаторов ожидал подобного поведения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:29:54 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitrm7mЕсли нужна еще какая либо информация с удовольствием предоставлю план на 2.5.2 не помешает. И на 2.5.0 заодно. Немного проблематично :( (постараюсь завтра-послезавтра) и еще одно уточнение запрос Код: sql 1. 2. 3. 4. работает ожидаемо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:34:23 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, Выполни следующий запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Результат выложи сюда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:41:51 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m> работает ожидаемо Забавненько. ДЕ, оптимизатор такие обманы пока не умеет замечать? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:52:41 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, кол-во индексных чтений и записей в результате отличаются ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:54:10 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамДЕ, оптимизатор такие обманы пока не умеет замечать? смотря что ты считаешь обманом :-) Второй вариант абсолютно понятен оптимизатору, а первый "обман" - нет. Один и тот же предикат нельзя использовать для двух индексных выборок, отсюда и результат в первом посте. Уверен что во всех версиях ФБ план будет такой же, т.е. используется лишь первый сегмент. А развернуть свернутую бинарную логику оптимизатор не умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 15:59:15 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
hvladm7m, кол-во индексных чтений и записей в результате отличаются ? Да запрос Код: sql 1. 2. 3. 4. возвращает 0 записей 16 индексных чтений запрос Код: sql 1. 2. 3. 4. возвращает 0 записей 0 индексных чтений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:11:18 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денисm7m, Выполни следующий запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Результат выложи сюда Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:20:56 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, после поста dimitr 14794983 всё уже понятно. Может быть в трёшке оптимизатор будет умнее в таких случаях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:31:30 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitrГаджимурадов РустамДЕ, оптимизатор такие обманы пока не умеет замечать? смотря что ты считаешь обманом :-) Второй вариант абсолютно понятен оптимизатору, а первый "обман" - нет. Один и тот же предикат нельзя использовать для двух индексных выборок, отсюда и результат в первом посте. Уверен что во всех версиях ФБ план будет такой же, т.е. используется лишь первый сегмент. А развернуть свернутую бинарную логику оптимизатор не умеет. Ну вот немного другая ситуация Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. запрос Код: sql 1. 2. 3. 4. 5. PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE, ACCOUNT_SERVICE_ACC_ENDDATE)) и получается что развернуть свернутую бинарную логику оптимизатор умеет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:33:30 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денисm7m, после поста dimitr 14794983 всё уже понятно. Может быть в трёшке оптимизатор будет умнее в таких случаях. ну оно вроде так, однако 14795294 практически тоже (ну другая таблица, ну три сегмента, но оптимизатор разобрался) и если-бы он здесь не разобрался то исходный вопрос не поднимался бы (хронологически сначала был разбор полетов с запросом 14795294 , а потом с 14794643 ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:41:10 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, Это не тоже самое. Здесь у тебя оптимизатор выбрал план по отдельным сегментам индекса ACCOUNT_SERVICE_ACC_ENDDATE один для поля ACCOUNTCODE, второй - ACCOUNT_PIPECODE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:42:39 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitr, а в трёшке в плане будет как-нибудь отражено какой именно сегмент индекса был выбран в таких случаях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:44:06 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, да, будет (в расширенном плане) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:51:08 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денисm7m, Это не тоже самое. Здесь у тебя оптимизатор выбрал план по отдельным сегментам индекса ACCOUNT_SERVICE_ACC_ENDDATE один для поля ACCOUNTCODE, второй - ACCOUNT_PIPECODE какое тогда будет объяснение для Код: sql 1. 2. 3. 4. 5. PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:54:32 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, ну а здесь всё понятно оптимизатор выбрал индекс целиком, а не по сегментам (раскрывать ничего не потребовалось) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:56:13 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7mи получается что развернуть свернутую бинарную логику оптимизатор умеет гммм, ты меня в тупик поставил :) Может я и ошибся выше. Примеры обоих случаев можешь предоставить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 16:58:59 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 17:05:27 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЭто не тоже самое. Здесь у тебя оптимизатор выбрал план по отдельным сегментам индекса ACCOUNT_SERVICE_ACC_ENDDATE один для поля ACCOUNTCODE, второй - ACCOUNT_PIPECODEДенис, ты не прав. Подумай и объясни нам - почему :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 17:06:20 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitrm7mи получается что развернуть свернутую бинарную логику оптимизатор умеет гммм, ты меня в тупик поставил :) Может я и ошибся выше. Примеры обоих случаев можешь предоставить? Примеры, в смысле базу с данными на котором это воспроизводится??? думаю что да, ну опять-же немного попозже, надо всё лишнее убрать, а это процесс длительный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 17:13:46 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, ок, буду ждать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 17:29:26 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
hvlad, Я действительно неправ. Но объяснить не могу. Код: sql 1. 2. 3. 4. PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE)) Вроде вспоминается что-то про битовые маски. Надо бы конечно ещё раз перечитать статью о методах доступа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 17:31:17 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitr> ок, буду ждать Только сообщить результаты исследования не забудь, пожалуйста. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 18:41:13 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, конечно. Даже если я таки ошибся выше, то IMHO причина будет банальна - что-то со статистикой. В баг я пока не верю, но посмотрим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 18:50:31 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Залил случайные данные 10000 строк через генератор в IBExpert. Обновил статистику. Код: sql 1. 2. 3. 4. 5. PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 19:02:15 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, правда версия 2.5.2.26539. Приду домой проверю на свежем снапшоте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 19:04:07 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, на снапшоте 2.5.3 тоже самое. Что-то ты не договариваешь. Не удаётся мне получить план PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE, ACCOUNT_SERVICE_ACC_ENDDATE)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 21:02:38 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денисm7m, на снапшоте 2.5.3 тоже самое. Что-то ты не договариваешь. Не удаётся мне получить план PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE, ACCOUNT_SERVICE_ACC_ENDDATE)) структуры таблиц, запросы и планы копировал из IBEpert'а завтра еще раз на свежую голову всё проверю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2013, 21:09:03 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЗалил случайные данные 10000 строк через генератор лабуда. 1. надо начинать с миллиона. 2. рандом тоже должен быть специфическим, чтобы дать желаемое количество дубликатов. Рандом по строке в 20 символов даст почти все уникальные значения. Напомню, что селективность индекса, это 1/(Keys - TotalDup), т.е. 1/(всего_ключей - всего_минус_повторы). например, 10к ключей, 1к повторов, это 1/(10000-9000). Чем меньше повторов, тем больше значение стремится к нулю. При 100% повторов значение будет равно 1/(10000-9999) = 1. Это наихудше возможная селективность индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 01:16:43 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
kdv, мы тут про случай когда оптимизатор разворачивает свёрнутую бинарную логику ТС утверждал, что у него оба запроса по 3х сегментному индексу дают одинаковый план Код: sql 1. 2. 3. 4. 5. PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE)) Код: sql 1. 2. 3. 4. 5. PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE, ACCOUNT_SERVICE_ACC_ENDDATE)) Мне такое сделать не удаётся. Хотя второй запрос даёт желаемый ТСом план. Может конечно там какие-то нюансы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 07:51:16 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, Удалось воспроизвести Код: sql 1. 2. 3. 4. 5. PLAN (ACCOUNT_SERVICE INDEX (ACCOUNT_SERVICE_ACC_ENDDATE, ACCOUNT_SERVICE_ACC_ENDDATE)) Сделал в Accountcode и Account_Pipecode всего одно значение. А дату равномерно распределённой. Так что похоже ничего там не раскрывается. Просто индекс берётся только по сегменту поля Enddate, т.к. по нему селективность выше. Однако непонятно как это состыковывается предложением в статье о методах доступа Дмитрий ЕмановИндексы могут быть простыми (односегментными) и составными (многосегментными или композитными). Следует отметить, что совокупность полей композитного индекса представляет собой единый ключ. Поиск в индексе может осуществляться как по ключу целиком, так и по его подстроке (подключу). Очевидно, что поиск по подключу допустим только для начальной части ключа (например, starting with или использование не всех сегментов композита). Если поиск осуществляется по всем сегментам индекса, то это называется полным совпадением (full match) ключа, иначе это частичное совпадение (partial match) ключа. Отсюда для композитного индекса по полям (A, B, C) следует, что: 1. он может быть использовать для предикатов (A = 0) или (A = 0 and B = 0) или (A = 0 and B = 0 and C = 0), но не может быть использован для предикатов (B = 0) или (C = 0) или (B = 0 and C = 0); 2. предикат (A = 0 and B > 0 and C = 0) приведет к частичному совпадению по двум сегментам, а предикат (A > 0 and B = 0) - к частичному совпадению всего по одному сегменту. В частности "но не может быть использован для предикатов (B = 0) или (C = 0)" Код: sql 1. Тут вроде как поле ENDDATE стоит последним. Или я что-то не догнал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 09:34:06 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. PLAN (ACCOUNT_SERVICE NATURAL) Совсем я запутался. Вообщем предложение в статье верное. Тогда не понятно как получается выше указанный план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 09:58:01 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7mструктуры таблиц, запросы и планы копировал из IBEpert'а завтра еще раз на свежую голову всё проверю Проверил, все свои слова подтверждаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 10:29:55 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitrm7m, ок, буду ждать отправил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 10:30:20 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
итак, разбор полетов запрос 1 (проблемный): Код: sql 1. 2. 3. 4. 5. 6. смотрим посегментную селективность индекса: Код: sql 1. 2. 3. видим, что использование последнего сегмента для выборки уменьшает ее размер (кардинальность) примерно в два раза. Т.е. объединение двух выборок по OR даст примерно ту же кардинальность, что и использование лишь первого сегмента однажды. Но при примерно равной стоимости выборки записей вариант с OR еще и удвоит стоимость чтения индекса, ибо будет два скана вместо одного. В попугаях там получается стоимость примерно 6 против 4 не в пользу варианта с OR-битмапом. Отсюда и результат. запрос 2 (хороший): Код: sql 1. 2. 3. 4. 5. 6. 7. смотрим посегментную селективность индекса: Код: sql 1. 2. 3. 4. видим, что использование последнего сегмента для выборки уменьшает ее размер (кардинальность) примерно в четыре раза. Т.е. объединение двух выборок по OR будет все еще в два раза дешевле, чем использование лишь первых двух сегментов однажды. Пусть с учетом стоимости индексных сканов это будет не в два, а лишь в полтора раза, но все равно дешевле. а вот добавляя еще одно условие в OR мы уже выйдем на уровень стоимости первых двух сегментов, если не хуже. Что сервер наглядно демонстрирует, отказываясь делать OR-битмап при трех OR-условиях: Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:12:03 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitrитак, разбор полетовОсталось сравнить рантайм статистику для разных планов, чтобы понять - прав оптимизатор или нет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:14:23 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitrвидим, что использование последнего сегмента для выборкиЯ бы сказал "использование двух (всех) сегментов для выборки". Ибо тут уже были абсурдные предположения, что можно использовать только второй сегмент для поиска... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:16:15 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitr> итак, разбор полетов Судя по описанию, оптимизатор во всех случаях оказался прав? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:21:55 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitr, Ага таки оптимизатор умеет разворачивать свёрнутую бинарную логику. Просто все мои предположения исходили из того, что он этого делать не может. Теперь всё понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:24:24 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денис> Ага таки оптимизатор умеет разворачивать свёрнутую бинарную логику С чего это? Просто её выгоднее пустить по одному плану, а не по другому. Это не совсем разворачивание, а просто подсчёт селективности сегментов. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:27:31 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, По описанию то прав, но m7mhvladm7m, кол-во индексных чтений и записей в результате отличаются ? Да запрос Код: sql 1. 2. 3. 4. возвращает 0 записей 16 индексных чтений запрос Код: sql 1. 2. 3. 4. возвращает 0 записей 0 индексных чтений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:28:38 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамСудя по описанию, оптимизатор во всех случаях оказался прав? по статистике прав, а как оно де-факто выйдет - ХЗ, зависит от реальных значений в полях. На предоставленной базе и именно этих константах в запросе он скорее неправ, но разница там субтильная (23 vs 27 фетчей). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:31:33 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамС чего это? Просто её выгоднее пустить по одному плану, а не по другому. Это не совсем разворачивание, а просто подсчёт селективности сегментов. Всё понеслось вот с этого ответа. Я ведь сначала даже поинтересовался у ТС селективностью сегментов. dimitrГаджимурадов РустамДЕ, оптимизатор такие обманы пока не умеет замечать? смотря что ты считаешь обманом :-) Второй вариант абсолютно понятен оптимизатору, а первый "обман" - нет. Один и тот же предикат нельзя использовать для двух индексных выборок, отсюда и результат в первом посте. Уверен что во всех версиях ФБ план будет такой же, т.е. используется лишь первый сегмент. А развернуть свернутую бинарную логику оптимизатор не умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:33:03 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitr, Спасибо!!!! зы. Для себя я понял что в принципе всё в порядке. и заставлять сервер использовать два раза индекс не буду :) :) :) ибо тем самым не оставлю оптимизатору никакого выбора тем более что (насколько я понимаю) по мере жизни базы селективность по первым сегментам ACCOUNTCODE , ACCOUNT_PIPECODE будет ухудшаться (ибо количество их практически не изменится) а по последнему сегменту - ENDDATE будет улучшаться и рано или поздно наступит "счастье" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 13:59:55 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitr> по статистике прав, а как оно де-факто выйдет - ХЗ, зависит от реальных значений в полях. Так это везде так. На этапе построения плана есть ведь только селективность. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 14:05:57 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Симонов Денис> Я ведь сначала даже поинтересовался у ТС селективностью сегментов. Так ДЕ же объяснил с конкретными цифрами. Возможно мы по-разному понимаем понятие разворачивания предиката - я (и ДЕ, AFAIU) имел в виду следующее: 1. where A = :A and (B = :B1 or B = :B2) есть сокращенный вариант развернутого where A = :A and B = :B1 or A = :A and B = :B2. 2. Это ручной обман (подсказка) оптимизатора и сам он такое (разворачивать предикат) не умеет. Наверное, это можно добавить, но ХЗ насколько это сложно и оправданно. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 14:13:54 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, Я именно так и понял. Хотя да, из слов ДЕ оптимизатор не разворачивает выражение. Но всё равно умеет использовать индекс дважды, если если стоимость получается более низкой. Кстати по идее с использованием гистрограмм может получится другая оценка, но вроде их использование возможно только для сравнения с константами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 14:31:28 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
Мысль тут у меня появилась, насколько дурная не знаю дабы не листать топик приведу исходный пост еще раз Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Запрос Код: sql 1. 2. 3. 4. показывает план PLAN (ACCOUNT_STATE INDEX (ACCOUNT_STATE_ACC_ED_DESC)) я ожидал PLAN (ACCOUNT_STATE INDEX (ACCOUNT_STATE_ACC_ED_DESC, ACCOUNT_STATE_ACC_ED_DESC)) зы. записей в таблице 268773 Статистика для обоих индексов 0,000003720611..... с планами и причинами таких планов объяснили, все понятно но вот возник вопрос в связи с выделенным текстом Если создать уникальный индекс ALTER TABLE ACCOUNT_STATE ADD CONSTRAINT UNQ1_ACCOUNT_STATE UNIQUE (ACCOUNTCODE, ENDDATE); то оптимизатор выбирает план PLAN (ACCOUNT_STATE INDEX (UNQ1_ACCOUNT_STATE, UNQ1_ACCOUNT_STATE)) ну собственно сам вопрос, а может можно оптимизатор научить смотреть еще на статистику PK, ну и надо ли его этому учить ??? ps/ Я прекрасно понимаю что сам себе буратино и в моём случае надо было самому указывать что индекс уникальный, однако могут быть случае когда индекс все-же не уникальный но "дублирование" совсем мизерное ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2013, 10:29:10 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
m7m, статистика для ПК принимается упрощенной, т.е. стоимость индексного скана = 2 и стоимость чтения записи = 1. Так специально сделано, ибо не генерить кривые планы при устаревшей статистике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2013, 12:22:26 |
|
||
|
Непонятки с оптимизатором 2.5.3
|
|||
|---|---|---|---|
|
#18+
dimitrm7m, статистика для ПК принимается упрощенной, т.е. стоимость индексного скана = 2 и стоимость чтения записи = 1. Так специально сделано, ибо не генерить кривые планы при устаревшей статистике. Я так понимаю что и для уникального индекса аналогично??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2013, 13:20:19 |
|
||
|
|

start [/forum/topic.php?all=1&fid=40&tid=1564343]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
164ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
96ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 494ms |

| 0 / 0 |
