|
|
|
Про IMMUTABLE и STABLE
|
|||
|---|---|---|---|
|
#18+
Опытным путем получено, что immutale и stable работает только в том случае, если функция возвращает одно значение, если функция возвращает набор значений или таблицу, то это не работает. В качестве теста использовались две функции, одна для изменения Volatility Categories, другая для вызова первой функции. первая функция Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. вторая функция Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Если в первой функции изменять тип возврата и Volatility Categories, то получаем см. первый абзац. Можно, конечно, предположить почему так, но хотелось бы найти ответы в документации. Или второй вариант, это не правильно поставлен эксперимент. Прошу поделиться своими соображениями. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 09:23:24 |
|
||
|
Про IMMUTABLE и STABLE
|
|||
|---|---|---|---|
|
#18+
big-trot, а какую ошибку оно у вас дает? PS: для оптимизатора в любом случае IMMUTABLE информация полезна ТОЛЬКО для тех функций которые возращают одну строку... во всех остальных случаях от этой информации пользы ровно 0 потому наверное и не дают ставить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:22:46 |
|
||
|
Про IMMUTABLE и STABLE
|
|||
|---|---|---|---|
|
#18+
IMHO, тест у вас некорректный. Значение даже immutable-функции не запоминается между несколькими SQL-выражениями. Но вывод правильный: результат функции типа set не кэшируется. В документации это явно не указано, а из исходников видно src/backend/optimizer/util/clauses.c Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Документации это не противоречит: там написано что оптимизатор *может* оптимизировать вызов функции, а не *должен* всегда это делать. В большом/сложном запросе можно обернуть вызов функции в WITH или в подзапрос. Но и в этом случае гарантии однократного вызова оптимизатор не даёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:23:53 |
|
||
|
Про IMMUTABLE и STABLE
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk а какую ошибку оно у вас дает? В данном случае никаких ошибок не возникает. Варьируя Volatility Categories получается различный результат по производительности. В случаях когда функция возвращает одно значения - Volatility Categories играет роль, иначе эта функциональность не имеет никакой значимости. As198IMHO, тест у вас некорректный. Значение даже immutable-функции не запоминается между несколькими SQL-выражениями. В документации написано, что immutable-функции выполняется на этапе построения плана запроса. В данном тесте функция вызывается при выполнении prepare, в цикле когда выполняется сам SELECT функция уже не вызывается, а используется закешированный результат, это очень хорошо видно, если сравнить время выполнения этой же самой функции, но как stable. По времени это разница в десятки раз. Если изменить тип возврата на set или table, то результат выполнения двух типов функции становится одинаково медленный, т.е. похоже immutable функция в цикле вызывается всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:06:32 |
|
||
|
Про IMMUTABLE и STABLE
|
|||
|---|---|---|---|
|
#18+
big-trotВ случаях когда функция возвращает одно значения - Volatility Categories играет роль, иначе эта функциональность не имеет никакой значимостиОт волатильности ещё зависти какой снапшот будут использовать запросы в функции, основного запроса (immutable|stable) или постоянно обновляемый (volatile). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 17:22:46 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38552805&tid=1998857]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
180ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 223ms |
| total: | 485ms |

| 0 / 0 |
