К сожалению VACUUM и REINDEX не помогли.
Как работает планировщик POSTGRES, для меня загадка.
Есть такая же БД на другом сервере, в аналогичных запросах,
там используется нужный индекс, который раньше использовался на проблемной базе.
Приведу элементарный запрос и планы выполнения
1.
2.
3.
SELECT Filed1
FROM Table1
WHERE Field2 like '01%' AND Fileld3 = 123
План запроса на проблемной БД:
1.
2.
3.
4.
5.
6.
7.
8.
9.
"Unique (cost=0.43..6.21 rows=1 width=8) (actual time=1.323..11.502 rows=184 loops=1)"
" Buffers: shared hit=4806 read=416"
" -> Index Scan using "Index1" on "Table1" (cost=0.43..6.20 rows=1 width=8) (actual time=1.320..11.473 rows=184 loops=1)"
" Index Cond: ("Filed3" = 123)"
" Filter: ("Field2" ~~ '01%'::text)"
" Rows Removed by Filter: 37833"
" Buffers: shared hit=4806 read=416"
"Planning time: 26.205 ms"
"Execution time: 11.571 ms"
Используется Index1 по полю Field2 с классом оператора varchar_pattern_ops, запрос выполнялся 25 секунд
С аналогичной БД на другом сервере
1.
2.
3.
4.
5.
6.
"Index Scan using "Index2" on "Table1" (cost=0.69..8.71 rows=1 width=8) (actual time=0.052..0.426 rows=184 loops=1)"
" Index Cond: (("Filed3" = 123) AND ("Field2" ~>=~ '01'::text) AND ("Field2" ~<~ '02'::text))"
" Filter: ("Filed2" ~~ '01%'::text)"
" Buffers: shared hit=189"
"Planning time: 0.558 ms"
"Execution time: 0.546 ms"
Используется Index2 по полям (Field2 с классом оператора varchar_pattern_ops, Field3), запрос выполнялся 50 миллисекунд
Как-то оптимизировать запрос нельзя, куда уж проще. У меня осталась последняя мысль, удалить Index1,
но будет ли во всех местах, где действительно нужен Index1, использоваться Index2 и не будет ли он тормозить эти запросы?
Буду рад любым конструктивным идеям
