Информация
- В рейтинге
- Не участвует
- Откуда
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Бэкенд разработчик
Средний
Java
Java Spring Framework
Spring Boot
Hibernate
SQL
Git
Алгоритмы и структуры данных
Английский язык
Netty
Спасибо за отзыв!
Про второй подход могу посоветовать цикл статей от Querify Labs - https://www.querifylabs.com/blog/memoization-in-cost-based-optimizers
Что касается деревьев запросов, если не изменяет память, брал информацию отсюда: Yongwen Xu: Efficiency In The Columbia Database Query Optimizer| Portland State University, 1998
Статья писалась не совсем для новичков, все-таки тема не самая простая, поэтому предполагается, что базовые вещи, вроде определения выборки и проекции читатель уже знает
А вот про деревья запросов далеко не в каждой книжке по БД пишут, по личному опыту знаю
Со вторым соглашусь, постараюсь в дальнейшем давать больше примеров
Начал разбирать вопрос, понял, что скорее потянет не на комментарий, а на отдельную статью. Если Вы не против, так и сделаю :)
Могу пока посоветовать прочитать публикацию Севидова П.Н. https://pandia.ru/text/81/114/5463.php, там вполне неплохо описывается генетический алгоритм в задаче оптимизации, и есть даже про JOIN с 5-ю таблицами
Что касается, разницы PostgreSQL и MySQL, могу сказать следующее: оба используют подход с левосторонними деревьями (снизу вверх), но в PostgreSQL оптимизатор работает немного лучше, так как MySQL использует подход П.Г.Сэлинджер напрямую, а PostgreSQL применяет модифицированный алгоритм Г.Моеркотта и Т.Ньюмана. Там суть в оптимизации построения деревьев, что позволяет быстрее выполнять вычисления и сразу отбрасывать часть неэффективных планов
Подробнее можете почитать в работе со страшным названием A Survey on Advancing the DBMS Query Optimizer: Cardinality Estimation, Cost Model, and Plan Enumeration
Согласен, CBO еще не гарантирует оптимальность запроса, всегда что-то может быть не учтено или статистики может не хватать, или баг может быть в конце концов
Как раз планирую небольшое исследование на эту тему, может будет в следующей статье :)
Точного ответа на этот вопрос дать не могу, т.к. с DB2 никогда не работал
Но могу выдвинуть предположение
В документации к DB2 написано:
The SELECTIVITY clause can only be used with basic predicates (as defined in the SQL reference), not predicates such as LIKE or BETWEEN. A lower selectivity value (very small number) will tell DB2 that the predicate will qualify fewer rows (and encourage use of indexes defined on that column). A higher selectivity value (close to 1) will mean the opposite.
То есть, если операция выборки из 10000 строк вернет 2, то использовать полный обход заведомо неразумно - слишком много операций впустую, поэтому в таких случаях можно заставить оптимизатор использовать индекс, даже если оценка с ним почему-то хуже, чем без него (например мало статистических данных, чтобы нормально кардинальность посчитать)Скорее всего, в примере оптимизатор решил, что без индекса лучше, а применение
SELECTIVITY 0заставило его передумать :)Вообще, как я понял, параметр
SELECTIVITYможно задавать любой от 0 до 1, и это будет как-то влиять на решения оптимизатора, но 0 - это что-то вроде насильственного использования индексаЧестно говоря, никогда не сталкивался с
SELECTIVITY 0в работе, поверхностное гугление тоже ничего не дало :(Могу предположить, что вопрос про низкоселективные индексы, если нет, можете, пожалуйста, дать конкретики, может какие-нибудь примеры?
Подскажите, пожалуйста, на ваш взгляд было тяжело читать из-за языка, плохой структурированности или чего-то еще?