Расширенная оптимизация подзапросов в Oracle


Сращивание и другие преобразования


В [8] мы обсуждали, как различные преобразования взаимодействуют друг с другом, и как инфраструктура преобразований, основанных на оценке стоимости, управляет возможными взаимодействиями. Сращивание подзапросов не является исключением, так как срощенный подзапрос стать предметом других преобразований. Подзапрос из Q5 может быть подвергнут преобразованию устранения вложенности, что приведет к запросу Q6, который содержит встроенное представление (производную таблицу) V:

Q6

SELECT s_name FROM supplier, lineitem L1, (SELECT LX.rowid xrowid FROM lineitem L2, lineitem LX WHERE L2.l_orderkey = LX.l_orderkey AND L2.l_suppkey <> LX.l_suppkey GROUP BY LX.rowid HAVING SUM(CASE WHEN L2.l_receiptdate >

L2.l_commitdate THEN 1 ELSE 0 END) = 0) V WHERE s_suppkey = L1.l_suppkey AND L1.rowid = V.xrowid;

После слияния представления из Q6 получается запрос Q7, в котором таблица LX оказывается избыточной, так как в слитом блоке запроса LX и L1 соединяются по столбцу rowid, обладающему свойством уникальности. Поэтому LX

удаляется, а все ссылки на нее заменяются ссылками на L1.

Q7

SELECT s_name FROM supplier S, lineitem L1, lineitem L2 WHERE s_suppkey = L1.l_suppkey AND L1.l_orderkey = L2.l_orderkey GROUP BY L1.rowid, S.rowid, S.s_name HAVING SUM(CASE WHEN L2.l_receiptdate > L2.l_commitdate THEN 1 ELSE 0 END) = 0);

Здесь мы имеем уже, как минимум, четыре альтернативных формулировки запроса. В большинстве случаев неясно, какая из четырех альтернатив является оптимальным выбором. Для поддержки принятия решения может быть использована инфраструктура преобразований Oracle, основанных на оценке стоимости, которая обсуждалась в подразделе 1.1.




- Начало -  - Назад -  - Вперед -



Книжный магазин