|
|
|
двойной select
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. Здравствуйте, есть возможность вывести так же записи, только без использования второго select ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 11:41 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
petrovichvanya, Для 12с: Код: plsql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 11:47 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
petrovichvanyaЗдравствуйте, есть возможность вывести так же записи, только без использования второго select ? Для семерки если есть индекс по operdate и operdate is not null Код: plsql 1. 2. 3. 4. ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 12:16 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
оба варианта не подошли, жаль( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 12:19 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
viking_dooh Код: plsql 1. 2. 3. 4. 5. Это без первого select, нужно без второго. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 12:35 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
petrovichvanya, CONTRACTID уникальное Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 12:55 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
viking_doohДля 12с: fetch first row only Из серии о сусликах: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 15:15 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
SYИз серии о сусликах (...)Опаньки.. Получается, FETCH FIRST .. - это даже хуже чем старое-доброе top-N ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 15:31 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
--Eugene--Опаньки.. Получается, FETCH FIRST .. - это даже хуже чем старое-доброе top-N ? Да нет: Код: 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. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 15:40 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
И что ты показал? Ну покажи на миллионе записей Там обычный COUNT STOPKEY уделает ROW_NUMBER() OVER (ORDER BY "A2"."SAL" DESC ) Это в общем-то давно известно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 15:47 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЭто в общем-то давно известно Воможно. Я думал и WINDOW SORT PUSHED RANK и SORT ORDER BY STOPKEY остановят сортировку после первых N. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 15:54 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
Насколько помню, там речь не про остановку сортировки COUNT STOPKEY хранит (ROWNUM<11) всего 10 последних максимальных/минимальных значений -- вся сортировка делается не более чем с 10 максимальными/минимальными значениями WINDOW SORT PUSHED RANK вроде должен делать тоже самое, но в большинстве случаев это не работает и идет полная сортировка по окну Да вроде, обсуждалось неоднократно Или это у меня "волшебные пузырьки"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 16:03 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровИ что ты показал? Ну покажи на миллионе записей Там обычный COUNT STOPKEY уделает ROW_NUMBER() OVER (ORDER BY "A2"."SAL" DESC ) Это в общем-то давно известно 600тысч, для rownun<10 разница незаметна .... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 16:23 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровНасколько помню, там речь не про остановку сортировки COUNT STOPKEY хранит (ROWNUM<11) всего 10 последних максимальных/минимальных значений -- вся сортировка делается не более чем с 10 максимальными/минимальными значениями WINDOW SORT PUSHED RANK вроде должен делать тоже самое, но в большинстве случаев это не работает и идет полная сортировка по окну Да вроде, обсуждалось неоднократно Или это у меня "волшебные пузырьки"?WINDOW SORT PUSHED RANK тоже так же работает, другое дело, что она сама по себе сложнее, поэтому и работает чуть дольше. Естественно, я не говорю о "with ties" или всяких RANK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 16:40 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
Спасибо, Но у меня, как правило, получались другие результаты Может версии были не те, но сложилось стойкое впечатление, что в простых случаях COUNT STOPKEY проще и быстрее WINDOW SORT PUSHED RANK В более сложных (в запросе кроме аналитики есть еще и общая сортировка) я даже не сомневался в этом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 16:55 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
StaxВячеслав ЛюбомудровИ что ты показал? Ну покажи на миллионе записей Там обычный COUNT STOPKEY уделает ROW_NUMBER() OVER (ORDER BY "A2"."SAL" DESC ) Это в общем-то давно известно 600тысч, для rownun<10 разница незаметна Не заметна. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 17:04 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
Заклевали Пойду дальше "пузырики" лопать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 17:07 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
xtenderWINDOW SORT PUSHED RANK тоже так же работает, другое дело, что она сама по себе сложнее, поэтому и работает чуть дольше. Естественно, я не говорю о "with ties" или всяких RANK Не поленился проверить. Версия 12.1.0.2.0, 2 node RAC на EXADATA: Код: 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. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 17:10 |
|
||
|
двойной select
|
|||
|---|---|---|---|
|
#18+
SY, прогнал сейчас тесты на 12.1.0.2(не экзадата) и 12.2.0.1(экзадата): по умолчанию "fetch first" был быстрее в 2 раза. Глянул статистики: fetch first на обычном сервере использовал serial direct path reads, а rownum - нет. На экзадате I/O fetch first: через cell smart table scan rownum: через cell multiblock physical read и cell multiblock read request Очевидно, что rownum своим включением режима оптимизации first rows (_optimizer_rownum_pred_based_fkr - enable the use of first K rows due to rownum predicate), отключает директридсы и смартскан. Пример с обычным сервером: Сделал Код: plsql 1. и стало примерно одинаково: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Пример с экзадатой: fetch first: 00:07:57.51 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. rownum c "_optimizer_rownum_pred_based_fkr"=false: 00:06:41.46 Код: 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. Так что по большому счету разницы нет и в случае со сложным запросом где реально работает ALL_ROWS разницы особой не будет. А для простых запросов, но по большим таблицам, там где реально нужна оптимизация ввода/вывода, там FKR портит всю картину, т.к. отключает эти оптимизации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2018, 00:59 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39744374&tid=1883070]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 354ms |

| 0 / 0 |
