Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Прошу помощи с оптимизацией запроса
|
|||
|---|---|---|---|
|
#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. Вот план выполнения: Код: 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. Наибольший вес тут имеет выполнение: Код: plaintext 1. 2. Вот индекс fixed_timedataIndex4: Код: plaintext 1. 2. 3. 4. 5. Вопрос: Можно ли сократить время выборки по данной таблице при прежних условиях? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2008, 16:05 |
|
||
|
Прошу помощи с оптимизацией запроса
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. убрать ненужное условие jt.building_site_id IN (1, 2). если условие jt.project_id IN (1, 2, 4, 5, 8, 9, 10, 11) - постоянное, то сделать частичный индекс с этим условием по jt(building_site_id,id). тогда при выполнении по плану NestedLoop(jt,td) даже отпадет необходимость в финальной сортировке. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2008, 17:21 |
|
||
|
Прошу помощи с оптимизацией запроса
|
|||
|---|---|---|---|
|
#18+
автор будет выполняться кроме HashJoin(jt,td) другими способами: HashJoin(td,jt), NestedLoop(jt,td), NestedLoop(td,jt), MergeJoin Каким образом можно изменить принцип объединения, использовать INNER (OUTER) JOIN ? автор если условие jt.project_id IN (1, 2, 4, 5, 8, 9, 10, 11) - постоянное, то сделать частичный индекс с этим условием ... Данное условие не постоянное, оно формируется приложением на основе переменных окружения. автор может быть вы опечатались? поиск по индексу с условием date>= можно выполнить только в том случае, если date - первое поле в индексе. Нет, не опечатался. Вот запрос на создание индекса: Код: plaintext 1. 2. 3. 4. 5. Вероятно, что я неправильно его составил. Если поле data стоит в индексе не первым, то оно не участвует в поиске? P.S. Версия Postgres 8.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2008, 17:44 |
|
||
|
Прошу помощи с оптимизацией запроса
|
|||
|---|---|---|---|
|
#18+
DDTКаким образом можно изменить принцип объединения, использовать INNER (OUTER) JOIN ?нет. с помощью изменения параметров планировщика set enable_* to off|on, например для начала сделать set enable_hashjoin to off. ещё создать нужные для определенного плана индексы, и даже возможно удалить ненужные, например, как я уже писал, для плана NestedLoop(jt,td) создать индекс по td(document.id). DDTНет, не опечатался. Вот запрос на создание индекса: Код: plaintext Вероятно, что я неправильно его составил. Если поле data стоит в индексе не первым, то оно не участвует в поиске?да, эффективный поиск (в плане обозначается IndexCond) по такому индексу с ограничением по полю date (на равенство или на неравенство) возможен лишь в том случае, если кроме этого присутствуют ограничения по полю id на равенство и по полю worker_id на равенство. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2008, 01:48 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=35368379&tid=2004293]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 272ms |
| total: | 428ms |

| 0 / 0 |
