|
|
|
Непонятки с оптимизатором 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 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38387222&tid=1564343]: |
0ms |
get settings: |
4ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
181ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 187ms |
| total: | 469ms |

| 0 / 0 |
