|
|
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Шавлюк ЕвгенийMaxim Boguk, А что даст запрос если в таблице будут 5 записей с ID = {1, 2, 2000000000, 2000000001, 2000000002} P.S. попал в топик с Хабра вот для такого "разделения по областям ключа" -- я и пытался накидать "на словах", скорее всего много что наврал (где-то лишние коленца), но примерная канва "выбрасывания гигантских дырок" ( понятно, что основной выйгрыш должен идти от индекс скана, кторого в тесте нет) где-то такая: Код: sql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2014, 15:20:22 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin<> это жесткий оффтоп, вот по этому поводу, в том числе, чтобы такого не было, я и предлагал вводить доп требования. можно найти по моему профилю, моим темам. ну зочем же так шапковозгораццо ? охолоните, что ли. тут вас больше одного, комсомольцев-то. во всех пальцем не натыкаесся. PS там, на хабре, поцыент вообще например пишед: авторПодвох обнаружился в самом "сердце" алгоритма — выборке записи из диапазона. Действительно, рекурсивный запрос пытается выбрать строчку, для которой выполнялось бы условие: Код: plaintext Но в случае, когда random() возвращает "1", это условие трансформируется в: ... и гордо лупцует себя пьяткой в хрудь я, хоть помню, что много раз себя перепроверял , что рандом пж возвращает открытый интервал , но всё равно полез в RTFM -- смотртеь с какого конца открыто: RTFM Код: plaintext и т.д. тащемто. рукалицо и порченный стыд. вот что карма и прочие комсомольские склонности с людяма делают ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2014, 16:02:10 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
PS: кстати сообразил: чтобы принудить пж к индекс скану -- поцыенту потребовалось кастнуть левую сторону r int-у Код: sql 1. ну вот тут кривизна пж бесконечна, и таковой и будет ближайшие лет 200, как объясняет нам smagen а дальше он попросту всё попутал -- полез на rendom() батоны крошить, когда причина -- в касте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2014, 16:12:21 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
PS . цена удаления дырок (т.е. усложнение алгоритма) получилась великовата. надо бы подсократить. привожу скрипты теста ddl Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. insert rnd with holes Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Bogyk Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ORDER BY random() на такой табличке быстрее всего Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 14random + 10^6row_number() поиск по оконному порядку дороже ? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. -- предподсчет count() удешевит на 0.1-0.2 removing BIG holes Код: sql 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. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. -- дороговато выходит восстанавливать карту дырок всякий раз, даже когда их всего 15 (15 интервалов в массивах) надо б удешевить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 13:36:34 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
PPS если слегка добавить рядков -- в 5 раз примерно, то наконец начинаем немного отыгрывать у full-scan- а Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: sql 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. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. и если перенести расчет карты дырок на моменты попадания в большие дырки ( а не высчитывать всякий раз), то немного ускоряемся: Код: sql 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. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. но не сильно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 15:44:34 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
?Ы, путем ковыряния в носу придумал такой алгоритм true рандома, который будет работать для этого случая. условия: 1) поле, по которому выбираем уникально 2) элементы расположены близко друг к другу, но существуют значительные "дырки" 3) число больших дырок < значения statistics target/2 (а лучше выкручиваем statistics для поля в максимум 10000) 4) статистика относительно аккуратная (autoanalyze собирает) take the best of both worlds: 1) выбираем границы диапазонов из имеющейся статистики, их у нас получится 10000 (если таблица большая конечно же) Код: sql 1. 2. 3. 4. 5. 2) сортируем диапазоны по их длине. тут нам нужно пометить те диапазоны, которые намного больше других - именно они и содержат дырки. можно по-разному это делать, например можно выделить те диапазоны, длины которых больше 2*median(len). получится что-то вроде такого: Код: 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. 3) алгоритмом Максима выбираем N диапазонов (могут повторяться, группируем потом по диапазонам) = сколько чисел нам надо выбрать 4) цикл по помеченным диапазонам (выборка из диапазонов с дырками): тут мы выбираем обычным order by random() с условиями по границам диапазона сколько элементов нам нужно. для каждого такого диапазона это всего будет index scan по 1/10000 строк таблицы. 5) цикл по непомеченным диапазонам: выбираем алгоритмом Максима столько элементов для каждого диапазона, сколько нужно. т.к. дырок больших в этих диапазонах нет - будет быстро 6) объединяем результаты 7) profit кодить это все не сильно хочется, но должно работать быстрее order by random (если только полтаблицы не выбирать конечно) и без краевых эффектов возле дырок. не важно, открытый интервал у random() или закрытый, все равно вероятность попасть в точку почти 0. а вот при касте происходит неявное округление, так что по 0.5 добавить не помешает, да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 17:37:17 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Alexius, снкс. разрабатывая ноздрю: если разбить на 2 отдельных этапа --1. вырезание дырок (наперёд не более некоего финитного кол-ва) --2. выборка рандомов тыканием в единожды размеченное "картой" мн-ве то : 1. на первом жестко получаем мн-во (TABLE) {Lmin,Lrange}, которое никогда не перевычисляем на 2-м 2. выбрасываем большинство накладных (на свертку/развертку array-ев) на 2-м этапе -- заменив (JOIN LATERAL (SELECT * FROM {L_CTE_table} ORDER BY .. LIMIT 1) с предподсчитанной CTE табличкой, про которую выше) => вероятно будем иметь тот же профит но -- без обращения к не обязательно актуальной статистике тут важно -- отжать всё лишнее с каждого из этапов. но при всюду редком заполнении (когда всюду дырки одного порядка) full scan на очень редких заполнениях (10^-6) выиграет всегда. (или надо уметь очень дёшево вырезать очень много дырок). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 19:57:59 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
?Ы, хм, при всюду редком заполнении можно ввести какое-нибудь поле с хешем небольшой длины, так получим более-менее равномерное распределение (при хорошей хеш функции), куда тыкать можно, но правда с дублями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 20:33:10 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
точнее поле можно и не создавать, только функциональный индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 20:36:37 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
вот как-то так например, берем первые 16 бит от md5 в качестве хеша Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Код: sql 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. 100 строк, 26ms. game over? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 21:16:45 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Alexius<> 100 строк, 26ms. game over ? до тез пор, пока я умышленно не прорежу именно по (('x'||md5($1::text))::bit(16)::integer); -- после чего игра потребует новой переиндексации (т.е. фуллскана ++) с новым хешем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 22:03:09 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Alexius, Hm не совсем. Там где будут коллизии 16битного хеша - скорее всего будет всегда выбираться первый в индексе с этим хешом... а остальные с тем же хешом не будут выбираться НИКОГДА. Достаточно неприятная особенность... учитывая что шанс коллизий на 16битах высокий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 22:17:47 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Maxim BogukAlexius, Hm не совсем. Там где будут коллизии 16битного хеша - скорее всего будет всегда выбираться первый в индексе с этим хешом... а остальные с тем же хешом не будут выбираться НИКОГДА. Достаточно неприятная особенность... учитывая что шанс коллизий на 16битах высокий. А увидел... order by random() каюсь да этой проблемы нет. Интересное решение факт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2014, 22:20:00 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, тут еще важно правильно выбрать длину хешей. оптимальной наверное будет такая, при которой для каждого значения будет по 10 записей из таблицы (postgres для hash join'ов такое же правило использует). т.е. вычисляем длину хеша по простой формуле (lg(N)-1)/lg(2), для моей таблицы в 1.6М записей получаем 17 бит. для 100 строк время снизилось до 18-20ms. таким образом получаем почти константное время выборки одной строки, не зависящее от размера таблицы. правда при изменении числа строк в таблице на порядок и больше желательно перехешировать с новой длиной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 06:36:58 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Alexius, Круто с хешом. Интересно, можно глянуть, если такого нету -- можно и на вики написать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 10:11:23 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Alexius 100 строк, 26ms. game over? помедитируйте над: Код: sql 1. 2. 3. 4. 5. 6. //если сходу неясно -- фтыкать до посинения резюме: пассажыр велосипедист, гружёный лишним знанием -- опаснее велосипедиста без башни [хотя бы тем, что врёт убедительней] простите, если кого обидел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 10:52:43 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
лопата, Интересное замечание. Я почему то ожидал заметно более равномерного распределения первых 16 бит md5 относительно того что получилось. Возможно первые биты md5 - неудачный алгоритм хеширования для этой задачи и надо что то другое делать (фундаментально оно может ситуацию не изменит но как минимум сделает ее достаточно плоской для практического применения). Но тут уже начинается суровый computer science. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 12:22:22 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
лопата, вопросы выбора хеш функции, качества получившегося рандома и применимости подхода к конкретной задачи открытые. я смотрел на это распределение и посчитал его удовлетворительным. у меня получилось как-то так: Код: sql 1. 2. 3. 4. 5. 6. 7. Код: 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. вот тут есть некоторые исследования http://michiel.buddingh.eu/distribution-of-hash-values если кто запилит хи квадрат тест и сравнит результат с другими хеш функциями будет хорошо. или найдет публикации, наверняка это сто раз уже исследовано. ну и никто не запрещает ввести индексируемое поле и заполнять его при вставке каким-нибудь рандомным числом в заданном диапазоне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 12:46:03 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, я ожидал разброса sqrt(avg(count(1)) -- по теорверу, типа (т.к. мы не подгоняли распределение под хеш ф-ю ). что уже фиксирует неравенство раз и навсегда (для любого заранее данного хеша и заданного распределения набора id). но, кажется, даже это ожЫдание не оправдалось (т.е. там другой собаки sqrt порылся) кто-то может вспомнить, как это делаецца по науке ? Дисперсия там, то ,сё. От числа бросаний, ага. Можно ж определить изначально ожидаемую "несправедливость" для случайно выбранной хеш ф-ии, и неизвестного наперёд распределения (через count(1)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 12:47:33 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Alexiusлопата, <> ну и никто не запрещает ввести индексируемое поле и заполнять его при вставке каким-нибудь рандомным числом в заданном диапазоне. как бы помяхше в общем рандом -- он несправедливый. [Если мы его взяли не один раз а повторили 100 раз один результат.] как и хеш. справедливо только 1-1. и рендомная выборка из 1-1 -- как гарантии равновероятности исходов. а вы замораживаете несправедливость (различие весов) для всех последующих якобы "рендомных" выборок. что неверно. поэтому предварительный рендом, рендом по невыстроенному мн-ву с фиксированными дырками, рендом по хешу -- одинаково гарантируют неравновероятность единожды замороженную на мн-ве. То, что несправедливость получена (раз за разом) случайным образом -- оно конечно греет. того, кто от неё вкушает. Ага. честным это будет только если каждый раз вы начнете выбират заведомом произвольную "заморозку" (хеш ф-ю с проихвольными сдвигами, и т.п.) -- а это -- каждый раз -- фулл скан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 12:56:50 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
хехехе на хабре этот малолетний далпайоп ещё и упирается, лять http://habrahabr.ru/post/242999/#comment_8129565 убивать, убивать , убивать ржавой лопатой только биореактор, только хардкор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 18:36:07 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, А подскажите, как такие сложные рекурсивные запросы отлаживать? Мне в голову приходит только PL/pgSQL функция с `RAISE NOTICE` возвращающая константу, которую CROSS JOIN-ить в рекурсивной части. Вот только что ей на вход давать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2014, 16:59:30 |
|
||
|
очередной велосипедист
|
|||
|---|---|---|---|
|
#18+
vyegorovMaxim Boguk, А подскажите, как такие сложные рекурсивные запросы отлаживать? Мне в голову приходит только PL/pgSQL функция с `RAISE NOTICE` возвращающая константу, которую CROSS JOIN-ить в рекурсивной части. Вот только что ей на вход давать?хотя там входит словцо recursive, никакой рекурсии нет, есть итерации (прямопроходные, а не обратный проход до корня, с возвратом), которые можно обрезать просто счетчиком итераций -- и смотреть за результатом. т.е. каждая итерация возвращает очередной "слайс" т.н. "working table", с этим слайсом "рекурсивно" (итеративно) делается UNION [ALL] - и результат поступает в следующую итерацию. И тоько в конце (т.е. в наружнем селекте) выплёвывается всё накопленное на итерациях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2014, 17:15:01 |
|
||
|
|

start [/forum/topic.php?fid=53&gotonew=1&tid=1998334]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
231ms |
get topic data: |
10ms |
get first new msg: |
6ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 241ms |
| total: | 588ms |

| 0 / 0 |
