Александр @SaZha
Middle Java Developer, SPSU graduate, ITMO student
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Specialization
Backend Developer
Middle
Java
Java Spring Framework
Spring Boot
Hibernate
SQL
Git
Algorithms and data structures
English
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
в работе, поверхностное гугление тоже ничего не дало :(Могу предположить, что вопрос про низкоселективные индексы, если нет, можете, пожалуйста, дать конкретики, может какие-нибудь примеры?
Подскажите, пожалуйста, на ваш взгляд было тяжело читать из-за языка, плохой структурированности или чего-то еще?