|
|
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
softwarer Дим, ты ухитрился в одной фразе поддержать точки зрения обеих принципиально не согласных сторон виртуальной дискуссии. Вообще-то я всего лишь пытался пнуть топикстартера, не желающего отвечать на вопрос о странной логике выборки записей... Вот если в форуме по Дельфи встретится человек, который заговорит о быстром получении ста тысяч записей в грид, ты поинтересуешься у него "а, собственно, зачем"? Сабж же подразумевает, что пользователь не только просмотрел эти сто тысяч записей, но и пометил десять тысяч из них галочкой. Боюсь, что на фоне времени, которое на это было потрачено, слово "эффективность" теряет всякий смысл. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 16:06 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov softwarer У некоторых людей регулярно используется обратная логика: Если кто-то не может молотком забить гвоздь в бетонную стену, то из них плохой: молоток, гвоздь или стена? молоток, поскольку надо взять монтажный пистолет. есть способ скормить в список in хоть сто хоть тыщу идентификаторов без ущерба для здоровья сервера, через коллекции. Выше об этом говорилось, только вместо коллекции был ассоциативный массив ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 16:08 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
softwarer- зрители вообще перестают что-либо понимать в происходящем. Такой уж ты загадочный ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 16:10 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov softwarer Дим, ты ухитрился в одной фразе поддержать точки зрения обеих принципиально не согласных сторон виртуальной дискуссии. Вообще-то я всего лишь пытался пнуть топикстартера, Я в данном случае говорю исключительно о связавшем нас фрагменте беседы. Я привел некий сценарий, ты в своем ответе фактически сказал, что правы обе стороны этого сценария - при том, что одна из них считает вторую явно неправой и некорректно себя ведущей. Я вижу в этом некое противоречие. Dimitry SibiryakovВот если в форуме по Дельфи встретится человек, который заговорит о быстром получении ста тысяч записей в грид, ты поинтересуешься у него "а, собственно, зачем"? Нет, не поинтересуюсь. Я "пну" тех, кто бросится кричать "такое никогда и никому не требуется потому что моя СУБД не может этого сделать". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 16:23 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Вообще-то я всего лишь пытался пнуть топикстартера, не желающего отвечать на вопрос о странной логике выборки записей... Логика простая: пользователь видит в гриде много записей, выделяет их и нажимает кнопочку, которая должна хитрым образом обработать выделенные записи. Вделить он их может как несколько, так и все (или почти все), нажав на "*" (инвертирование выделения). зы: я не считаю, что грузить 10 тыс записей на клиента - это бад дезигн, это удобство. Около 3500 записей, полученные запросом сорока полей из пятнадцати таблиц, грузятся в грид за 2 сек. (это в трёхзвенной архитектуре), далее локально работает грид от DevExpress (сортировка, фильтры по каждой колонке). зы2: Firebird 2.1 :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 17:55 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Hello, NickDee! You wrote on Wed, 22 Oct 08 14:55:58 GMT: NickDee N> зы: я не считаю, что грузить 10 тыс записей на клиента - это бад дезигн, это удобство. похоже боржоми пить уже поздно... -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 18:02 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
NickDee Вделить он их может как несколько, так и все (или почти все), нажав на "*" (инвертирование выделения). В этом случае надо применять NOT IN (). Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 19:16 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
softwarerНет, не поинтересуюсь. Я "пну" тех, кто бросится кричать "такое никогда и никому не требуется потому что моя СУБД не может этого сделать". Честно скажу, если искренне говоришь, то не могу не уважать мнение. Только давайте вспомним тему топика, если кто забыл (что немудрено). Тема: автор Эффективная выборка записей по списку ID Много было сломано копий, много выдумано сравнений про "бетон и молоток". Но самое главное осталось за бортом. Я говорю про эффективность . Насколько будет эффективен запрос с предложенными условиями? Я не то чтобы не умею выражаться аллегориями, но не имею такой склонности. Посему предлагаю просто протестировать запрос с предикатом WHERE ... IN (<до_фига_элементов>). С передачей в виде запроса и с предварительной перекачкой набора IDшников на сервер. Я не силен в Oracle, но могу сравнить запросы с клиента в Firebird и MSSQL. Адептам Oraсle (и других СУБД) предлагаю провести аналогичный тест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 22:18 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov В этом случае надо применять NOT IN (). нужно понимать, что есть ещё и фильтр (как серверный "where", так и локальный). вот как выглядит эта несложная конструкция на Firebird: Код: plaintext 1. 2. 3. Код: plaintext 1. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 07:40 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
NickDee нужно понимать, что есть ещё и фильтр (как серверный "where", так и локальный). Вот к этому-то фильтру и нужно добавлять условие IN/NOT IN. И будет тебе счастье, поскольку, как сказал Ё!, сервер перейдёт на Range scan, что и повысит эффективность. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 12:08 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov NickDee нужно понимать, что есть ещё и фильтр (как серверный "where", так и локальный). Вот к этому-то фильтру и нужно добавлять условие IN/NOT IN. И будет тебе счастье, поскольку, как сказал Ё!, сервер перейдёт на Range scan, что и повысит эффективность. Во-первых: сложно(читай долго), во-вторых: пока ты у себя что-то фильтровал, другие юзеры уже могли натоптать пачку новых записей, это конечно тоже можно учесть, но мне кажется что несколько десятков миллисекунд сервера можно потратить и на доступ по ID-ам. А может даже такой способ в большинстве случаев эффективней индексированного (и частично неиндексированного) поиска по куче полей (не проверял). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 14:28 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Senya_LНо самое главное осталось за бортом. Я говорю про эффективность . Насколько будет эффективен запрос с предложенными условиями? Во-первых, автор спрашивал "как эффективнее" - так? Поэтому насчет предложенных условий... Senya_LПосему предлагаю просто протестировать запрос с предикатом WHERE ... IN (<до_фига_элементов>). С передачей в виде запроса и с предварительной перекачкой набора IDшников на сервер. .. Я не силен в Oracle, ... "Предварительная перекачка" - это очевидный идиотизм, тестировать который нет нужды. Ну а чтобы удовлетворить Вас... Выборка из десяти миллионов строк одной тысячи (с десятью тысячами принципиальной разницы не будет, но тогда текст sql вылезет за пределы varchar, придется извращаться), сравниваем "список в in" и "передачу коллекции" Код: 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. 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. Итого выводы: Разницы по скорости не заметно План в эксперименте в целом одинаковый На этапе построения плана оптимизатору неизвестно количество элементов в коллекции, что приводит к наколеночной оценке количества строк, и как результат, может привести к неоптимальному плану и необходимости использования хинта cardinality ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 15:52 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
P.S. Коллеги - я вполне понимаю, что этот эксперимент можно улучшить и сделать более глубокие выводы.. например таки заметить разницу между range scan и unique scan и отметить поведение оптимизатора. Я здесь не ставлю такой цели, я всего лишь хочу показать, что "сплеча наезжать на перечисление в where" совершенно не обязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 15:58 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
в firebird конструкция "in" оказалась крайне не эффективна. Execute time на 1500 ID-шников (это максимум в FB) в 10 раз больше чем если воспользоваться join-ом (300 мс против 30) (Reads from disk to cache = 0) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 18:57 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Hello, NickDee! You wrote on Thu, 23 Oct 08 15:57:26 GMT: NickDee N> в firebird конструкция "in" оказалась крайне не эффективна. Execute time на 1500 ID-шников (это максимум в FB) N> в 10 раз больше чем если воспользоваться join-ом (300 мс против 30) (Reads from disk to cache = 0) на какой версии? ибо сие правилось. -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 19:04 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий последний релизнутый Firebird 2.1.1.17910 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 19:56 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Hello, NickDee! You wrote on Thu, 23 Oct 08 16:56:14 GMT: NickDee N> последний релизнутый Firebird 2.1.1.17910очень интересно. и тестовый кейс есть? -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 20:10 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий и тестовый кейс есть? Код: 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. В процедурке GET_BY_IN нужно заполнить 1500 элементов в "IN" :) EXECUTE PROCEDURE FILL_SOMETABLE - встявляет 10 миллионов записей (около минуты) Процедурку List заменил на List2, для простоты. Дальше можно открывать процедурки GET_BY_JOIN и GET_BY_IN в IBExpert-e и запускать их с фетчем(execute and fetch all) и сравнивать результаты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 20:48 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
NickDee пишет: N> Автор: NickDee N> в firebird конструкция "in" оказалась крайне не N> эффективна. Execute time на 1500 ID-шников (это максимум в N> FB) в 10 раз больше чем если воспользоваться join-ом (300 N> мс против 30) (Reads from disk to cache = 0) Попробовал твой пример: 78 мс против 280 мс на FB 2.0.3 125 против 460 на 2.1.0 (другая машина, хилая совсем) соотношение 1:4 примерно, но не 1:10 Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2008, 10:26 |
|
||
|
Эффективная выборка записей по списку ID
|
|||
|---|---|---|---|
|
#18+
МикросекундаNickDee пишет: N> Автор: NickDee N> в firebird конструкция "in" оказалась крайне не N> эффективна. Execute time на 1500 ID-шников (это максимум в N> FB) в 10 раз больше чем если воспользоваться join-ом (300 N> мс против 30) (Reads from disk to cache = 0) Попробовал твой пример: 78 мс против 280 мс на FB 2.0.3 125 против 460 на 2.1.0 (другая машина, хилая совсем) соотношение 1:4 примерно, но не 1:10 размер страницы 16K IN: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2008, 11:51 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=35610043&tid=1553035]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 160ms |

| 0 / 0 |
