Pull to refresh
11
0
Александр @SaZha

Middle Java Developer, SPSU graduate, ITMO student

Send message

Спасибо за отзыв!
Про второй подход могу посоветовать цикл статей от 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 в работе, поверхностное гугление тоже ничего не дало :(
Могу предположить, что вопрос про низкоселективные индексы, если нет, можете, пожалуйста, дать конкретики, может какие-нибудь примеры?

Подскажите, пожалуйста, на ваш взгляд было тяжело читать из-за языка, плохой структурированности или чего-то еще?

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