формируется запросом/функцией, оно вычисляется для каждого обращения независимо? это фича? )
Пример - https://www.db-fiddle.com/f/cTow7V1zeYy4W6bqyqFx9E/0
Соответственно в данном примере Subplan3, Subplan5, Subplan7 и .т.д одинаковые, и никакого смысла в их дополнительном выполнении вроде нет...
Правильным поведением кажется было бы единоразовое вычисление Subplan3 и Subplan4 и далее их использование в остальных OR условиях
Насколько я понимаю, постгрес сначала подставляет текст запроса на место обращения к вьюхе, и только потом начинает оптимизировать что-то. К этому моменту догадаться, что какие-то куски запроса повторяются, становится не так просто. Это называется сommon subexpression elimination. Это далеко не у всех языков программирования оптимизирующие компиляторы умеют, не то что планировщики запросов в СУБД... Не уверен что оракловый оптимизатор так умеет даже.
проверил - не умеет. ''' select (select max(id) from T1) m1, (select max(id) from T1) m2 from dual; ''' — в плане честно два индекс-скана.
ну, если бы оракловый оптимизатор был достаточно умный, он мог бы увидеть, что два раза делается одно и то же, сделать индекс-скан один раз и просто одну цифру вернуть два раза. Но не видит. Постгресовый планировщик делает так же, собственно. Понятно, почему так: для двух данных запросов произвольной сложности проверить, что они одинаковые — это прямо целая задача. А ещё надо учитывать, что запрос теоретически может обращаться к функциям, имеющим побочные эффекты, тогда однократное его исполнение может вернуть не те результаты. Короче ну его нафиг, решили авторы оптимизатора — пусть авторы запросов не страдают наркоманией и не пишут одинаковых подзапросов :)
я не в курсе как деталях работает планировщик, но кажется задача понять что идет обращение к одной и той же колонке вьюхи не выглядит сложной, а именно из этого и следует что они одинаковые, да и пишущий запрос тоже скорее всего так думает, даже если там и лежат фукнции ниже которые возвращают разные результаты (ужас вообще что будет). еще в теории можно оценить сложность "материализации" на лету, и ее выполнить, если она выгоднее выходит.
Обсуждают сегодня