|
|
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Один и тот же скрипт с разным условием выбирает разные методы выполнения и как следствие разное время на выходе, как это исправить оставив метод с минимальным временем выполнения? Инфа: Скрипт 1: Код: 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. Результат: Код: 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. Скрипт 2: Код: 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. Результат: Код: 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. Индексы: (данный индекс создавался для другого похожего запроса и оправдал себя в нём на 2000%, в отличие от данного) Код: plsql 1. 2. 3. 4. 5. Код: plsql 1. 2. 3. 4. 5. Разница в скриптах в отличие от времени их выполнения смешная: Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 14:20:14 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, тут явно неудачно оценивается в первом запросе селективность триграмного индекса можно отключить его использование костылем через замену Код: plsql 1. на например Код: plsql 1. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 15:00:12 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Забыл про один момент - скрипт неизменен(вшит в приложение безвозвратно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 15:02:32 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_meЗабыл про один момент - скрипт неизменен(вшит в приложение безвозвратно). никак или удалить trigram index --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 15:11:07 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukits_meЗабыл про один момент - скрипт неизменен(вшит в приложение безвозвратно). никак или удалить trigram index --Maxim Boguk www.postgresql-consulting.ru а причину почему он так меняет своё настроение от одной буквы(варианты, предположения)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 15:19:01 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_meMaxim Bogukпропущено... никак или удалить trigram index --Maxim Boguk www.postgresql-consulting.ru а причину почему он так меняет своё настроение от одной буквы(варианты, предположения)? прогоните: explain analyze select count(*) from attribute_value where UPPER(string_value) like UPPER('%пис%'); explain analyze select count(*) from attribute_value where UPPER(string_value) like UPPER('%пись%'); explain analyze select count(*) from attribute_value where UPPER(string_value) like UPPER('%пис%') and attribute_code IN ('NAME'); explain analyze select count(*) from attribute_value where UPPER(string_value) like UPPER('%пись%') and attribute_code IN ('NAME'); тогда я что то смогу сказать. Но на практике использование attribute_value таблиц - к проблемам на любой базе ВСЕГДА И БЕЗ ВАРИАНТОВ. Это самый худший известный мне дизайн-антипаттерн для базы. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 15:59:22 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. Код: plaintext 1. 2. 3. 4. 5. Код: plsql 1. Код: plaintext 1. 2. 3. 4. 5. Код: plsql 1. Код: plaintext 1. 2. 3. 4. 5. 6. Код: plsql 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 16:26:13 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, сложно сказать но основная проблема в том что база ожидает 10000 строк отUPPER(string_value) like UPPER('%пись%') а получает миллион строк... какой уж тут эффективный план угадать. без переписывания запросы вы эту задачу не решите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 16:50:29 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
можно ли создать другой индекс, чтобы на него клюнул, например типа: Код: plsql 1. 2. 3. 4. 5. но такой выдает ошибку... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 16:59:39 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, для такого индекса надо btree_gin contrib доставить (и то без гарантий) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 17:09:19 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, тьфу тоесть btree_gist конечно в вашем случае ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 17:09:51 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Я не общался с ним, что надо сделать чтобы попробовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 17:15:47 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, Код: sql 1. дистинкт тут какбе говорит нам, что все джойны играют роль исключительно условия проверки существования, т.е. вместо EXISTS( .... LIMIT 1) вы поднимаете все записи по джойну, а потом от них долго и упорно дистинкститесь. За это надо руки из опы рвать с корнем. я так думаю. но если вы не можете переписать запрос -- снесите этот индекс ,или поставьте btree_gist и сделайте таки составной в триграмом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 17:18:55 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, надо сказать Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 17:20:33 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
кхмits_me, надо сказать Код: sql 1. Это ясно, а как создать индекс и как он работать будет(как мой "нерабочий")? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 17:35:40 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, создайте как хотели выше. btree_gist позволяет в т.ч. микс на уровне составного индекса. http://www.postgresql.org/docs/9.3/static/btree-gist.html а как и будет ли "работать" -- проверите, расскажете. я бы, наверное, переписал на exists (SELECT 1 ...) -- гарантировал бы nested loop по нужным индексам ORDER BY- ем LIMIT 1; Но не факт. в кач-ве фантастики -- при вводе атрибутов запрещайте вхождение слишком частых триграммов. пусть пользователи придумывают сильно уникальные имена ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2014, 17:53:36 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Создал вместо индекса test_pg_trgm_string_value_idx, индекс: Код: plsql 1. 2. 3. 4. 5. Для %пись% результат: Код: 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. для %пис%: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2014, 14:11:25 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, у вас очень оптимистичные ожидания [, не подтверждаемые в части actual], по количеству записей в av99. Т.ч. проще снести триграм нафик. PS покрутите таки тупой подсчет каунтов до размножения джойнами (по exists) сто-то на тему (надеюсь не наврал на предмет формальной эквивалентности): Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2014, 14:49:15 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Код: plsql 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. Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2014, 19:18:05 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
up ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 10:39:04 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
up ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2014, 12:33:22 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, а чего вы хотите? вам же сразу написали : автортут явно неудачно оценивается в первом запросе селективность триграмного индекса и это никуда не делось. перепишите запросы правильно, под ваше распределение данных. Поцгрес хорошая машинка, но бедна по части оптимизатора. у меня вот случай, когда Код: sql 1. "вдоль" индекса f1_idx (в плане) считается в разы быстрее чем Код: sql 1. "вдоль" индекса f2_f1_idx -- при достаточно селективном, на мой вкус f2 LIKE $3. -- что довольно контринтуитивно при этом можно считать что 1. таблица практически кластеризована по f1_idx 2. вероятно изрядная его [f1_idx] часть все время в кеше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2014, 13:12:34 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Запросы не изменить. Я так понял надо смириться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2014, 14:19:57 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Сам никогда не пробовал, но, возможно, вам подойдёт костыль под названием RULE: CREATE RULE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2014, 05:11:38 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
Как его применить если имеются и другие аналогичные запросы для которых не надо применять это правило? Есть запросы содержащие Код: plsql 1. 2. 3. 4. 5. 6. и которым не надо будет применять правило замены селекта(иначе не пройдет через нужный индекс). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2014, 10:30:18 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38819588&tid=1998301]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
177ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 482ms |

| 0 / 0 |
