Два bitmap index скана вместо одного

С дорогим ilike

Вышли план)

"Bitmap Heap Scan on table  (cost=536.47..538.49 rows=1 width=1910) (actual time=14897.883..14897.897 rows=2 loops=1)"
"  Recheck Cond: (((key)::text = '4070281000300043883'::text) AND ((comment)::text * '%аренды земельного уч%'::text))"
"  Heap Blocks: exact=2"
"  Buffers: shared hit=6229 read=5464"
"  ->  BitmapAnd  (cost=536.47..536.47 rows=1 width=0) (actual time=14897.835..14897.836 rows=0 loops=1)"
"        Buffers: shared hit=6227 read=5464"
"        ->  Bitmap Index Scan on idx_key  (cost=0.00..12.22 rows=488 width=0) (actual time=0.092..0.092 rows=409 loops=1)"
"              Index Cond: ((key)::text = '4070281000300043883'::text)"
"              Buffers: shared hit=7"
"        ->  Bitmap Index Scan on trgm_idx  (cost=0.00..524.00 rows=1067 width=0) (actual time=14897.726..14897.726 rows=2 loops=1)"
"              Index Cond: ((comment)::text * '%аренды земельного уч%'::text)"
"              Buffers: shared hit=6220 read=5464"
"Planning time: 1.184 ms"
"Execution time: 14898.081 ms"

С теста

На проде все подольше)

CREATE EXTENSION IF NOT EXISTS btree_gin

а включите track_io_timing, сделайте SELECT pg_reload_conf() и покахите EXPLAIN (analyze, buffers)

меня смущает вот это вот:

actual time=14897.726..14897.726
Buffers: shared hit=6220 read=5464

44MB прочитали с диска. и это заняло 2.5 минуты. какая у вас дисковая?

Уже не сегодня. Я делал, большая часть времени запроса на дисках, и это логично

сколько RAM, сколько shared_buffers?

Это плохо, лечите

Хмм... а кто-нибудь знает, что вот это такое (что за оператор):

((comment)::text * '%аренды земельного уч%'::text)

Это же не ILIKE, нет? Или это какие-то проблемы с копированием планов (иначе откуда там кавычки вокруг)?

actual time=14897.726..14897.726
Buffers: shared hit=6220 read=5464

Я там много странного видел. Например чтобы извлечь из gin 400 строк - читалось около 1 млн буферов

Bloat?

Скорее всего. Но не настолько же)

2 строки всего по comment, так и хочется CTE по key

Реакция внешнего инструмента кластеризации на самоизоляцию далеко не мгновенная.
Тем более, мастер коммитит в clog независимо от slaves даже при синхронной реплике.

Но здесь нужен индекс по двум полям

Это, как раз, бывает — ищутся же триграммы, а не непосредственно то, что видно в условии (т.е. false positives может быть хоть половина индекса).

> Если просто удалить\отключить GIN индекс, то ПГ просто отбирает

Интересно, как выглядит и вот этот план.