|
|
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
hi all вот тут dimitr привел пример цикла в 1 млн итераций с бенчмарком произв-сти rdb$get_context -vs- stored_func - vs- stored_func_deterministic. Вариант deterministic-функции рвёт всех как тузик грелку. Но там приведет вариант возврата из неё константы, а мну надо возвращать (сингулярный) результат запроса из базы. Решил сбацать вот такую детерм. функцию: Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Trace : всё супер, соединение rdb$types cross join rdb$types было выполнено только 1 раз: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1) повторный запуск этого же скрипта показал, что к rdb$types опять была ходьба, те же 130032 фетча. 2) если в запросе упомянуть функцию три раза (например), то ФБ выполнит её также три раза так, как будто бы она еще не выполнялась: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. И уж тем более ничего не помнит про свои результаты при НОВОМ стейтменте. Это так и было задумано ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 00:14:43 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ТаблоидИ уж тем более ничего не помнит про свои результаты при НОВОМ стейтменте. Ну это-то и ежу понятно: не в мировом же эфире ей хранить значение. Ты попробуй посмотреть что происходит при повторном вызове препарированного запроса. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 00:37:01 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovпопробуй посмотреть что происходит при повторном вызове препарированного запроса.Попробовал. Как-то взгрустнулось внезапно... test: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. trace: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 00:49:15 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
То, что детерминированность не работает при трёхкратном вызове в одном запросе - понятно, так желают только извращенцы, на этот случай забили. С разными запросами тоже понятно: мирового эфира нет. А вот оправдать препарированный запрос в одной не-рц транзакции я не могу. Недоработочка, похоже... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 00:59:46 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovС разными запросами тоже понятно: мирового эфира нет.Мировой зефир есть: rdb$get_context() откуда-то берёт при повторном вызове значение для соотв-щей переменной. Что мешает сделать такое же поведение для determ-функции ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 01:03:32 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ТаблоидЧто мешает сделать такое же поведение для determ-функции ? Нужно вместо "deterministic" написать "constant" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 04:44:18 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovА вот оправдать препарированный запрос в одной не-рц транзакции я не могу. Недоработочка, похоже... препарированный запрос может выполняться в транзакциях с любым уровнем изоляции, поэтому инварианты приходится сбрасывать перед очередным выполнением запроса. Теоретически, можно было бы как-то идентифицировать инварианты всех запросов транзакции в ее рамках и кешировать их значения в ее пуле. Но такого у нас пока нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 10:53:19 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ТаблоидЭто так и было задумано ? в текущем коде - да, так. Ничего специально для детерминированных функций без параметров не выдумывалось, она просто считается инвариантом и работает по тем же принципам, что и другие инварианты. Т.е. вычисляется и кешируется на уровне текущего выполнения данного запроса. В будущем можно подумать о кеше значений детерминированных функций на уровне коннекта, с маппингом входных значений на выходные без их повторного вычисления. Но это пока не планировалось к реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 10:58:56 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
dimitrНичего специально для детерминированных функций без параметров не выдумывалось, она просто считается инвариантом и работает по тем же принципам, что и другие инварианты.ага, вот оно что... а я сижу и репу чешу, чего это: Код: plaintext 1. 2. 3. 4. 5. - перечитывает rdb$types на каждой строке вот этого: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 2585 fetches, 1255 NR rdb$types Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 12:26:03 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
Таблоид, ты помечтай пока, а там посмотрим :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 12:34:44 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
dimitrты помечтай пока, а там посмотрим :-)я всё таки застолбил мечталку, дабы не утонула. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 13:04:55 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
dimitrТеоретически, можно было бы как-то идентифицировать инварианты всех запросов транзакции в ее рамках и кешировать их значения в ее пуле. Но такого у нас пока нет. По здравому сну я пришёл к выводу, что это не стоит выделки. Предположим, есть функция, возвращающая число записей в какой-то таблице. Между запросами оно может измениться даже в пределах одной транзакции с любым уровнем изоляции. Будет нехорошо, если функция вернёт старое значение. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 13:22:45 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovесть функция, возвращающая число записей в какой-то таблице. Между запросами оно может измениться даже в пределах одной транзакции с любым уровнем изоляции. Будет нехорошо, если функция вернёт старое значение.ну так и determ.-функцию здесь нефиг применять. Зато прикинь, какой шоколад будет, когда в determ-функцию передаем аргумент (= мнемоническому имени какой-нибудь константы приложения), а она наверх ИДшник выдаёт. Для таблиц, которые практически не меняются - самое оно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2014, 13:26:33 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоид, ты помечтай пока, а там посмотрим :-) Жаль что не в 3.0. А так мечталось, что слово deterministic будет работать именно для параметрических функций. Хотя надо признать, что PSQL-функции, при замене подзапросов из процедур дали в некоторых случая прирост на порядки(!), а не только синтаксическое удобство вызова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2014, 23:22:02 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ТаблоидЗато прикинь, какой шоколад будет, когда в determ-функцию передаем аргумент (= мнемоническому имени какой-нибудь константы приложения), а она наверх ИДшник выдаёт.Почему ПК не сделать мнемоническим именем? Чтобы функции потом писать? ТаблоидДля таблиц, которые практически не меняются - самое оно.result_cache в оракле легко забирает кучу памяти и забивает систему блокировками при вытеснении по lru данных из кэша если комбинаций входных параметров у кэширующих функций достаточно много. Еще одни потенциальные грабли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2014, 05:53:26 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ГхостикТаблоидЗато прикинь, какой шоколад будет, когда в determ-функцию передаем аргумент (= мнемоническому имени какой-нибудь константы приложения), а она наверх ИДшник выдаёт.Почему ПК не сделать мнемоническим именем? Чтобы функции потом писать?int = 4 байта, мнемоники - до 30, наверное. Умножь на число записей, а если поле индексированное, то и про индексы не забудь (я про дочерние таблицы, ссылающиеся своими полями на справочник констант; у нас есть такие). ГхостикТаблоидДля таблиц, которые практически не меняются - самое оно.result_cache в оракле легко забирает кучу памяти и забивает систему блокировками при вытеснении по lru данных из кэшаНеудивительно, если по дефолту выделять на него (result_cache) только 1% от шаред-пула. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2014, 07:14:20 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
Таблоидint = 4 байта, мнемоники - до 30, наверное. Умножь на число записей, а если поле индексированное, то и про индексы не забудь (я про дочерние таблицы, ссылающиеся своими полями на справочник констант; у нас есть такие).Давно уже производительности поставлен приоритет ниже чем удобству разработки. Ну и вот такой объем данных ухудшает производительность линейно, с этим бороться проще (добавлением железа) чем с комбинаторным взрывом или кривыми руками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2014, 08:14:07 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ГхостикТаблоидint = 4 байта, мнемоники - до 30, наверное. Умножь на число записей, а если поле индексированное, то и про индексы не забудь (я про дочерние таблицы, ссылающиеся своими полями на справочник констант; у нас есть такие).Давно уже производительности поставлен приоритет ниже чем удобству разработки.Тут золотую середину надо искать. Какой толк в удобстве разработки, если в итоге будет тормоз-прога ? Побьют ведь... :-) И скажи честно: у тебя не было разве случаев поиска+замены по всему приложению какого-то "красивого", но неэффективного, куска кода на некий "некрасивый", но зато быстрый ? Не на этапе разработки, ес-сно, а когда уже эксплуатация пошла. ГхостикНу и вот такой объем данных ухудшает производительность линейно, с этим бороться проще (добавлением железа) чем с комбинаторным взрывом или кривыми руками.Попробуй замерить DML на таблице с индексами, глубина которых <=3, а затем то же самое, но на индексах с глубиной >=5 (просто страницу базы сделай сначала 16К, а затем 4К, и натолкай в таблицу 100-150 млн строк). Разница *не* будет линейной. Железо поменять - проще всего (если бабло выделят), но ведь это не решение проблемы, а перенос на другой день. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2014, 08:34:27 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ГхостикПочему ПК не сделать мнемоническим именем?Есть и еще один аргумент против этого. Незначительный, но всё же. Имена констант иногда выбираются неудачно, их надо менять. И тогда в случае, когда они сидят в непосредственно в полях таблиц, надо будет гемороиться с этими таблицами: отрубать индексы с триггерами (чтобы не ждать по 5 часов), делать апдейты, врубать индексы обратно. А если мнемоники заданы только в справочном поле, то достаточно исправить только исходники. Повторюсь: это редкий случай, но он таки может произойти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2014, 08:41:39 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ТаблоидИ скажи честно: у тебя не было разве случаев поиска+замены по всему приложению какого-то "красивого", но неэффективного, куска кода на некий "некрасивый", но зато быстрый ? Не на этапе разработки, ес-сно, а когда уже эксплуатация пошла.Было, конечно. Но - это один случай из 100. Ради него выбирать неудобный для разработки способ и в остальных 99? ТаблоидРазница *не* будет линейной.С таблицей > 1e7 записей разговор всегда особый, с ней можно (и нужно) отдельно повозиться. И пойти на отходы от общих принципов в угоду производительности - можно, денормализация из той же оперы. Но не надо с нее начинать и считать правильным выбором изначально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2014, 09:07:38 |
|
||
|
deterministic stored function: не помнит своих результатов при повторном вызове/упоминании
|
|||
|---|---|---|---|
|
#18+
ТаблоидПопробуй замерить DML на таблице с индексами, глубина которых <=3, а затем то же самое, но на индексах с глубиной >=5 (просто страницу базы сделай сначала 16К, а затем 4К, и натолкай в таблицу 100-150 млн строк). Разница *не* будет линейной. Железо поменять - проще всего (если бабло выделят), но ведь это не решение проблемы, а перенос на другой день. Зачем? По мне так страницу 4K сегодня уже никто не ставит. Тут выбор обычно стоит между страницей 8K и 16K. ИХМО размер страницы по умолчанию при создании БД в трёшке надо изменить на 8K ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2014, 09:51:41 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38582714&tid=1563815]: |
0ms |
get settings: |
10ms |
get forum list: |
23ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
187ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 251ms |
| total: | 560ms |

| 0 / 0 |
