Комментарии 16
Спасибо! Вы свели действительно огромное количество граничных юзкейсов в одном месте.
Для меня лично открытием оказалась возможность «грязных чтений» при использовании функций в запросах. На практике с таким сталкиваться, правда, не приходилось, но, как говорится, «век живи — век учись» :-)
Одна небольшая ремарка: наименование пункта «Кэширование deterministic функций в PL/SQL» не совсем соответствует действительности — все-таки, вернее было бы «Кэширование deterministic функций в циклах PL/SQL». И, если говорить про этот сценарий, как вы правильно процитировали того же Фойерштайна, «похоже, что применимость этих оптимизаций будет весьма узкой»
Для меня лично открытием оказалась возможность «грязных чтений» при использовании функций в запросах. На практике с таким сталкиваться, правда, не приходилось, но, как говорится, «век живи — век учись» :-)
Одна небольшая ремарка: наименование пункта «Кэширование deterministic функций в PL/SQL» не совсем соответствует действительности — все-таки, вернее было бы «Кэширование deterministic функций в циклах PL/SQL». И, если говорить про этот сценарий, как вы правильно процитировали того же Фойерштайна, «похоже, что применимость этих оптимизаций будет весьма узкой»
граничных юзкейсов
Что вы подразумеваете под "граничными юзкейсами"?
Для меня лично открытием оказалась возможность «грязных чтений» при использовании функций в запросах.
Все остальное уже знали? Читали мои статьи?
Одна небольшая ремарка: наименование пункта...
Просто продолжение у меня так до сих пор в планах. То некогда, то лень написать остальное.
Что вы подразумеваете под «граничными юзкейсами»?
Возможно, стоило выражаться точнее. Я имел в виду сравнительно редкие / мало влияющие на относительно распространенные сценарии использования ситуации. Те же хэш-коллизии в SSC и Deterministic — не думаю, что частый случай. Аналогично и с оптимизацией в циклах. Аналогично, понимание специфики реализации (в т.ч. роли внутренних недокументированных параметров), безусловно, полезно, но и без него инструмент можно и нужно применять.
Все остальное уже знали? Читали мои статьи?
Кроме 1, 3.3 и 3.4 — да, знал. Пункт 4 — «знал, но забыл» — когда-то давно читал про это в вашей или очень похожей на вашу статье (жаль, что ваш сайт плохо ищется в Google, возможно, где-то видел перепечатку)
возможность «грязных чтений» при использовании функций в запросах
Это не грязное чтение, а несогласованное. Существенная разница.
Отличное дополнение к той статье, спасибо.
Ещё, в тему резалт-кеша и вообще кэширования в oracle-субд, сразу вспомнился доклад Александра Токарева, из датаарт.
Ещё, в тему резалт-кеша и вообще кэширования в oracle-субд, сразу вспомнился доклад Александра Токарева, из датаарт.
Кстати, расшифровка этого доклада есть на хабре: habr.com/ru/company/oleg-bunin/blog/414401
Да, жаль, что Александр не указывал источники…
либо функции не должны содержать запросов внутри, либо надо создать SQL оператор для нее
Либо использовать изоляцию READ ONLY.
Нет, это не поможет. Могли бы помочь flashback queries (select… from t as of scn/timestamp...), но это требует правок запросов в функции и передаче SCN в функцию и еще не просроченного undo
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Oracle: Deterministic functions, result_cache and operators