|
Планировщик выбирает seq_scan
|
|||
---|---|---|---|
#18+
Добрый день! Ситуация как из топика " Почему не используется индекс из двух полей при выборке только по первому полю? ", но есть отличия. Есть запрос: Код: 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.
При выполнении запрос, планировщик считает, что seq_scan в данном случае выгоднее, чем сходить в индекс: Код: plaintext 1. 2. 3. 4. 5.
Но, если отключить seq_scan, то он выбирает уже план с индексом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Сбор статистики по call_legs.session_id уже увеличен до 10000. pg_stats.n_distinct = -0.19461073 pg_class.reltuples = 206 427 152 (это к тому, что статистика обновляется) Общее количество строк в таблице = 206 468 782 Количество строк за нужный период = 6 763 138 Количество уникальных строк за период = 1 989 633 PostgreSQL 10.5 Настройки PG: cpu_index_tuple_cost = 0.005 cpu_operator_cost = 0.0025 cpu_tuple_cost = 0.01 parallel_setup_cost = 1000 parallel_tuple_cost = 0.1 random_page_cost = 10 (hdd) seq_page_cost = 1 effective_cache_size = 30GB default_statistics_target = 400 А теперь вопрос: Возможно как-то еще подсказать планировщику, что в данном случае план с индексами будет оптимальнее? Потому что, на текущий момент, кажется, что решить подобную проблему можно только введением дополнительных условий фильтрации. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2020, 14:49 |
|
Планировщик выбирает seq_scan
|
|||
---|---|---|---|
#18+
kap1lan, если у вас реально физически random_page_cost = 10 (hdd) seq_page_cost = 1 то прочитать все страницы последовательно из call_legs может быть быстрее чем читать 313832 строк случайным чтением с использованием индекса.. если вам надо чтобы планировщик предпочитал index scan over seq scan можно крутить 3 параметра 1)сильно повышать effective_cache_size но он нелинейно работает 2)уменьшать random_page_cost в пределе до == seq_page_cost 3)увеличивать cpu_tuple_cost учитывая что у вас при index scan 99.99% обращений к таблице идут Buffers: shared hit=3141803 read=31 через память а не с диска... то я делаю вывод что ваши настройки seq/random page cost не соответствуют тому что у вас в реальности с данными в базе наблюдается (с учетом кеширования в памяти базы и OS). я бы просто random_page_cost бы уменьшал... НО если вдруг окажется доступ к тем данным что на диске реально а не в кеше - random index scan может легко оказаться сильно медленнее. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2020, 15:00 |
|
Планировщик выбирает seq_scan
|
|||
---|---|---|---|
#18+
Maxim Boguk, спасибо за быстрый ответ. Про hdd, не совсем так, как я написал. Есть условная храникал, в которой массив каких-то дисков, поэтому для упрощения написал, что там hdd. ssd точно нет. Код: plaintext
Скорее всего, тут моя вина, не дождался, пока данные вытеснятся из файлового кеша. Перепроверю этот момент. Параметры покручу, посмотрим, как это повлияет на оценки планировщиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2020, 16:00 |
|
Планировщик выбирает seq_scan
|
|||
---|---|---|---|
#18+
kap1lan Maxim Boguk, спасибо за быстрый ответ. Про hdd, не совсем так, как я написал. Есть условная храникал, в которой массив каких-то дисков, поэтому для упрощения написал, что там hdd. ssd точно нет. Код: plaintext
Скорее всего, тут моя вина, не дождался, пока данные вытеснятся из файлового кеша. Перепроверю этот момент. Параметры покручу, посмотрим, как это повлияет на оценки планировщиком. Код: plaintext
файловый кеш OS для базы не отличим от дисков физических ps: а сколько у вас shared buffers ? pps: выбор между index scan / seq scan на 90% определяется именно значениями random_page_cost / seq_page_cost -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2020, 16:07 |
|
Планировщик выбирает seq_scan
|
|||
---|---|---|---|
#18+
Maxim Boguk, в shared_buffers сейчас 7Gb, общее на сервере 64Gb. Есть несколько еще java приложений на сервер, они суммарно забирают примерно 5Gb. Остальное использует (или мне так кажется) PG. Да, планировщик начал ходить в индекс, после изменения random_page_cost = 1. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2020, 16:35 |
|
|
start [/forum/topic.php?fid=53&fpage=24&tid=1994547]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
others: | 36ms |
total: | 195ms |
0 / 0 |