Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Возникает при извлечении данных: таблица: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. параметров разных (param_id) - около 500... и их необходимо выводить в строчку на каждое одинаковое event_datetime: Код: plaintext 1. 2. 3. 4. 5. 6. Код: 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. EXPLAIN ANALYZE запроса со 120 параметрами дает вот что: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. заранее благодарен! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 15:26 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Тут уже обсуждалось подобное http://www.sql.ru/forum/actualthread.aspx?tid=190031 P.S. "Кто виноват? Да ты сам и виноват. Что делать? Что-то другое" (c) О.Дивов извините, не сдержался... :) Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 15:52 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
собственно... это я ветку открывал тогда... варианты которые рассматривались - все до единого дико тормозят... просто не пойму - имеет ли смысл копать глубже (понятно - что всегда имеет и я не против - просто время поджимает не кстати)... или нужно перепроектировать базу под внешний вид... вот в чем дилемма) P.S. касательно P.S. знаю... к этому все и идет) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 16:21 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Аидрей wrote: > собственно... это я ветку открывал тогда... > варианты которые рассматривались - все до единого дико тормозят... Интересно, мой вариант тоже дико тормозит? http://www.sql.ru/forum/actualthread.aspx?tid=190031#1602114 Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 16:27 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Признаюсь - не уделил пристального внимания предложенному вами варианту... Просто на тот момент хотелось это сделать... красиво, что ли... (хотя почему именно за красивую сторону принял сторону базы - не могу объяснить... казалось, что так должно быть побыстрее) Сейчас уже важно - сделать быстрым все это... поэтому если позволите я немного более детально расспрошу вас о предложенном варианте: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 17:19 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Аидрей Насколько я понял - необходимо сначала вытащить все возможные данные вручную... а потом их вставлять в таблицу... (то ли я не понял основной тонкой мысли, то ли это не очень быстро должно выйти, imho) Да, идея в том, чтобы вытянуть все интересующие данные без километровых вложенных SQL подзапросов, группировок и сортировок [ну, почти], а далее растолкать их по соответсвующим ячейкам таблицы. По поводу скорости - должно работать вполне приемлимо, т.к. используется всего два простых запроса, объем которых не превысит в любом случае результаты вышеприведенных SQL (чаще должны быть существенно меньше). При "расталкивании" по ячейкам таблицы может тормозить ArrayList.IndexOf, (хотя не знаю наверняка) что можно ускорить, используя хеш-таблицы. несколько измененный код (если где-то навру с синтаксисом - сильно не пинать!): Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 18:10 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Извиняюсь за вновь прибытие. Согласен, что мой вариант будет тормозить, так как я немного ошибся :-) Нафиг было запихивать case в подзапрос, сам не понимаю. Кстати, а DISTINCT там обязателен? В моем варианте его небыло. Пожалуйста, сообщи результат такого варианта (pleeaase): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 09:28 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Funny_FalconКстати, а DISTINCT там обязателен? В моем варианте его небыло. Пожалуйста, сообщи результат такого варианта (pleeaase): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. По поводу DISTINCT - я пытался разобраться - в чем тормоза (а в силу того, что пока делитант) - выполнил отдельно вложенный SELECT - оказалось, что он возвращает кроме всего прочего - кучу записей с NULL - вот я и решил их пообрезать - скорость поднялась примерно раз в 15-20... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 10:48 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
XM По поводу скорости - должно работать вполне приемлимо, т.к. используется всего два простых запроса... спасибо =) думаю буду попробовать такой вариант =) кстати хочется спросить (исходя из опыта) - а данные в таблице будут отрисовываться по мере поступления, или по завершению... просто может это как-то в отдельный поток уводить, чтобы не было у пользователя сложностей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 11:15 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
Аидрей wrote: > кстати хочется спросить (исходя из опыта) - а данные в таблице будут > отрисовываться по мере поступления, или по завершению... просто может > это как-то в отдельный поток уводить, чтобы не было у пользователя > сложностей... Это уже как сами решите, стоит ли уводить в отдельный поток :) Мой пример - просто создает двумерный массив с соответственно расставленными данными. Варианты отрисовки (и оценка, тыксказть, юзабилити:) : 1. (не очень приятный, но чуть быстрее) Повесить сообщение "Получение данных. Ждите...", выгрести все данные и потом скопом отбразить. 2. (чуть приятнее, но чуть медленнее - затраты на UI refresh?) Повесить ProgressBar : "Получение данных...30%" (при этом для оценки процентов потребуется еще один запрос типа "select count(*) from period_avg_params WHERE datetime_id = ? "), выгрести все данные и потом скопом отбразить. 3. (для желающих видеть данные по мере выгребания) настроить Grid на соотв. размеры и добавлять данные по мере чтения. В запросе потребуется добавить "order by event_datetime". 4. Комбинация 2 и 3 :) Лично я бы выбрал вариант 2. (сугубое ИМХО :) Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 11:52 |
|
||
|
ОООочень низкая производительность
|
|||
|---|---|---|---|
|
#18+
По поводу DISTINCT - я пытался разобраться - в чем тормоза (а в силу того, что пока делитант) - выполнил отдельно вложенный SELECT - оказалось, что он возвращает кроме всего прочего - кучу записей с NULL - вот я и решил их пообрезать - скорость поднялась примерно раз в 15-20... Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2005, 14:45 |
|
||
|
|

start [/forum/topic.php?fid=53&gotonew=1&tid=2007097]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
132ms |
get topic data: |
11ms |
get first new msg: |
6ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 225ms |
| total: | 468ms |

| 0 / 0 |
