
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
27.07.2015, 12:17
|
|||
|---|---|---|---|
|
|||
Немного вопросов по функциям |
|||
|
#18+
Доброго времени суток! Решил часть часто-используемого кода вынести во VIEW, но т.к. ранее этим не пользовался, полез в сеть за объяснялками и примерами. Во многих местах советуют в случае необходимости параметров писать функцию. Ладно, посмотрел как это делается, написал вот такое: Код: plsql 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. Запустил в SQL-менеджере, запросило две даты и выдало результат. Все устроило. Ну собственно, возникли вопросы: Эта функция и есть "хранимая процедура" или это еще какой-то дополнительный механизм? В настройках видел еще такой описатель LANGUAGE 'sql' , чем это лучше/хуже чем LANGUAGE 'plpgsql' ? Или вообще не заморачиваться? При написании было много ругни на возвращаемые типы, пришлось каждому добавить "приведение" в виде ::INTEGER. Вопрос какого лешего если они и так целые? Или где я ошибаюсь? Написал изначально для помещения в аргументы констант, получаемых из GUI. Но, почитавши далее, понял, что данную функцию в принципе можно использовать как обычную таблицу. Если это действительно так, подскажите плс как, к примеру, сделать FULL OUTER JOIN с другой таблицей, чтобы использовались поля с другой таблицы в качестве аргументов. Табличка примера ниже. Код: plsql 1. 2. 3. 4. 5. 6. WBR, Majestio ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2015, 12:50
|
|||
|---|---|---|---|
|
|||
Немного вопросов по функциям |
|||
|
#18+
MajestioЭта функция и есть "хранимая процедура" или это еще какой-то дополнительный механизм? В рамках PostgreSQL это одно и то же. MajestioВ настройках видел еще такой описатель LANGUAGE 'sql' , чем это лучше/хуже чем LANGUAGE 'plpgsql' ? Или вообще не заморачиваться? "Это вообще три разных человека". "sql" - это просто sql "plpgsql" - это процедурный язык похожий на plsql MajestioПри написании было много ругни на возвращаемые типы, пришлось каждому добавить "приведение" в виде ::INTEGER. Вопрос какого лешего если они и так целые? Или где я ошибаюсь? С 9 версии PostgreSQL ужесточил типизацию. Так что нужно обязательно явно указывать возвращаемый тип. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2015, 12:59
|
|||
|---|---|---|---|
|
|||
Немного вопросов по функциям |
|||
|
#18+
mad_nazgul , спасибо за понятный ответ! :) Еще бы на последний вопрос какой-нить инфы ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2015, 15:59
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
plpgsql медленне чистого sql У вас чистый sql. Можете поменять Код: sql 1. 2. 3. 4. 5. 6. 7. 8. на Код: sql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2015, 16:02
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
ТСНаписал изначально для помещения в аргументы констант, получаемых из GUI. Но, почитавши далее, понял, что данную функцию в принципе можно использовать как обычную таблицу. Если это действительно так, подскажите плс как, к примеру, сделать FULL OUTER JOIN с другой таблицей, чтобы использовались поля с другой таблицы в качестве аргументов. Табличка примера ниже. 1) Вам не тяжело смотреть на ваш код? Перейдите на запросы CTE (WITH ...) Указывайте хоть сто таблиц в запросе. 2)В функции можете писать несколько команд, разделенных точкой с запятой ; Последней командой выведите результат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2015, 17:10
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
PCContra <> 1) Вам не тяжело смотреть на ваш код? Перейдите на запросы CTE (WITH ...) Указывайте хоть сто таблиц в запросе. никогда (в текушей реализации CTE в PG ) не используйте CTE, особо к большим таблицам, если не хотите целенаправленно материализовать промежуточный результат. т.е. никогда не следуйте советам некоторых местных клоунов, выделивших себя любовью к лаконичности стиля деклараций ПЖ. В отличии от оракла -- тут CTE не алиас, а всегда -- материализованный набор. Пользуйтесь этим, как хинтом , если нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2015, 18:24
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
qwwqт.е. никогда не следуйте советам некоторых местных клоунов, выделивших себя любовью к лаконичности стиля деклараций ПЖ. Не понял, чем смотреть на with в каждом запросе лучше view или функции, но для начала противпису нужно продемонстрировать параметризацию with. Majestioв случае необходимости параметров писать функцию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 10:22
|
|||
|---|---|---|---|
|
|||
Немного вопросов по функциям |
|||
|
#18+
PCContra, спасибо за советы, отдельные приму на вооружение :) По поводу CTE ... уже достаточно давно решил для себя по минимуму этим пользоваться, а лучше вообще не пользоваться. Причиной тому были словленные тормоза на одном из моих "монстриков"-запросов. Переписал тогда, запрос заметно ускорился. Вообщем остался "осадочек" :) И тут я где-то согласен с qwwq , чисто интуитивно. Увы, моя практика использования SQL слишком краткосрочна, приходится учится "на лету". Ценность многих решений нивелируется недостаточной практикой, поэтому часто пишу не совсем эффективно, но понятно мне (когда скорость выполнения получается приемлема). Для примера, вот один из запросов, которым формирую один из своих отчетов: Код: plsql 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. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. Поэтому, в той функции для меня не все так страшно, страшно получается позже :) О5 же, чисто интуитивно понимаю, что в продемонстрированном выше вполне бы мог использовать crosstab вместо кучи джоинов. Но ... до сих пор не понимаю, как тот же crosstab может развернуть результат по отсутствующему в выборке полю. Вернее понимаю, нужно собственно это поле добавить в подзапрос, а потом в вышележащем запросе его выинуть... Но как сделал - так мне нагляднее. Скорость выполнения приведенного на 5000 записях основной таблицы - около пол-секунды, меня это устраивает. Прогноз роста таблицы - около 1000 записей/год. Еще раз всем спасибо за советы. И это .... и все же последний вопрос моего первого поста ... Напишите плс маленький пример, если это несложно для вас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 10:32
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
qwwqтут я где-то согласен с qwwq, чисто интуитивно Надо посмотреть будет, взять на заметку. qwwq у нас суровый, краснодарские пацаны все такие ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 10:58
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
qwwqникогда (в текушей реализации CTE в PG ) не используйте CTE, особо к большим таблицам, если не хотите целенаправленно материализовать промежуточный результат. т.е. никогда не следуйте советам некоторых местных клоунов, выделивших себя любовью к лаконичности стиля деклараций ПЖ. Maxim Boguk PS: 15 лет работы с Postgresql приучили к тому что самые простые и дубовые решения лучше всего если они обеспечивают приемлемую производительность (так как были моменты когда через 3 года после запуска я не мог понять как работает особо хитрая система написанная лично мной в подобном стиле :)). Каждый сам по себе решает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 11:00
|
|||
|---|---|---|---|
|
|||
Немного вопросов по функциям |
|||
|
#18+
qwwq никогда (в текушей реализации CTE в PG ) не используйте CTE, особо к большим таблицам, если не хотите целенаправленно материализовать промежуточный результат. qwwq , выделенное осознал (частично) и запомнил :) Для полного понимания, раз уж пошел разговор об этом, хотелось бы выяснить остальные моменты, "оставшиеся за кадром". Собственно, вопрос ... И все же, есть ли такие ситуации, когда CTE является наилучшим решением, приносящим наибольший профит? Или "никогда" нужно понимать буквально как "никогда", без всяких "если"? А если все же такие ситуации есть, каковы они, каковы их отличительные признаки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 11:44
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
Majestio, блин, читатели, надо отличать конструкцию "никогда $1..если не $2" от всеобщего "никогда $1" там же написано -- когда даже нужно, и является навязыванием материализации гораздо более обязательным, чем хинты оракла. вообще говоря "никогда, $1 к большим таблицам, если размер мат-й выборки будет большим, и вы не понимаете, что вы этим хотите достигнуть" в этом смысле "вложенный подзапрос" -- гораздо более "простое по Богику" решение, чем CTE. Ибо оставляют простор в планировании оптимизатору. Насколько я понял писиконтрика -- он именно на вложенные подзапросы батоны крошит. Или булки мнёт. А это -- тупость и непонимание разницы физической реализации. Вот если бы CTE был реализован как алиас к вложенному, а не как материализованный темповый набор -- тогда бы речи за простоту имели бы основание. А пока -- нет. ну да, ещё я любитель пользоваться CTE в конструкциях WITH recursive -- для организации ручного index--seek [nestedloop] там, где это не умеет оптимайзер ПЖ. Но большая часть этого исскюства отмирает за ненадобностью с появлением внятного LATERAL( ... LIMIT ...) . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 12:38
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
MajestioИ все же, есть ли такие ситуации, когда CTE является наилучшим решением, приносящим наибольший профит? Или "никогда" нужно понимать буквально как "никогда", без всяких "если"? А если все же такие ситуации есть, каковы они, каковы их отличительные признаки? Есть такие ситуации. Если вам надо использовать наборы-агрегаты с небольшим количеством данных от большой таблицы несколько раз. Или не агрегат, а просто что-нить заковыристое, например, каждая N-я точка на графике+ экстремумы+начало и конец, чтобы это потом использовать для чего-то ещё. То есть сам итог маленький, а исходная табличка - большая. Пишу иногда сильно помороченные запросы для отчётов - очень выручает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 15:00
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
qwwqну да, ещё я любитель пользоваться CTE в конструкциях WITH recursive -- для организации ручного index--seek [nestedloop] там, где это не умеет оптимайзер ПЖ. Но большая часть этого исскюства отмирает за ненадобностью с появлением внятного LATERAL( ... LIMIT ...) Можно ссылку на примеры, пожалуйста, - заинтересовала технология. Я использую with, где результат небольшой (на мой взгляд), а выборка сложная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 18:03
|
|||
|---|---|---|---|
Немного вопросов по функциям |
|||
|
#18+
PCContraqwwqну да, ещё я любитель пользоваться CTE в конструкциях WITH recursive -- для организации ручного index--seek [nestedloop] там, где это не умеет оптимайзер ПЖ. Но большая часть этого исскюства отмирает за ненадобностью с появлением внятного LATERAL( ... LIMIT ...) Можно ссылку на примеры, пожалуйста, - заинтересовала технология. Я использую with, где результат небольшой (на мой взгляд), а выборка сложная один из вариантов , из частоупотребительных, был где-то изложен в т.ч. у максима в pdf. и тут. -- реализация DISTINCT при наличии индекса и большой повторяемости. Случай не единственный, но как шаблон--паттерн -- оно всё довольно однотипно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 18:10
|
|||
|---|---|---|---|
|
|||
Немного вопросов по функциям |
|||
|
#18+
PCContraqwwqну да, ещё я любитель пользоваться CTE в конструкциях WITH recursive -- для организации ручного index--seek [nestedloop] там, где это не умеет оптимайзер ПЖ. Но большая часть этого исскюства отмирает за ненадобностью с появлением внятного LATERAL( ... LIMIT ...) Можно ссылку на примеры, пожалуйста, - заинтересовала технология. Я использую with, где результат небольшой (на мой взгляд), а выборка сложная Вот тут вот лежит http://pgday.ru/files/pgmaster14/max.boguk.query.optimization.pdf -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2015, 18:25
|
|||
|---|---|---|---|
|
|||
Немного вопросов по функциям |
|||
|
#18+
Maxim BogukPCContraпропущено... Можно ссылку на примеры, пожалуйста, - заинтересовала технология. Я использую with, где результат небольшой (на мой взгляд), а выборка сложная Вот тут вот лежит http://pgday.ru/files/pgmaster14/max.boguk.query.optimization.pdf -- Maxim Boguk www.postgresql-consulting.ru А правильный вынос мозга на счет WITH (RECURSIVE) и вообще реализации сложных итеративных алгоритмов в SQL запросах тут: http://astarsan.livejournal.com/6465.html и его разбор http://astarsan.livejournal.com/6895.html -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=53&tablet=1&tid=1997306]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
147ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 476ms |

| 0 / 0 |
