Telegram-канал pgsql - pgsql – PostgreSQL: Unsorted

pgsql – PostgreSQL

04 March 2025 14:32

Всем привет. Есть вот такая табличка

db=# \d+ sometable
Table "public.sometable"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
---------+--------------------------+-----------+----------+-------------------------------------------------+----------+--------------+-------------
col1 | integer | | not null | | plain | |
col2 | timestamp with time zone | | not null | | plain | |
col3 | character varying(128) | | not null | | extended | |
col4 | character varying(32) | | not null | | extended | |
hstore_col | hstore | | | | extended | |
id | bigint | | not null | nextval('sometable_id_seq'::regclass) | plain | |
Indexes:
"sometable_pkey" PRIMARY KEY, btree (id)
"index_hstore" btree ((hstore_col -> 'email'::text)) WHERE col4::text = 'sometext'::text
Access method: heap
Options: autovacuum_vacuum_scale_factor=0.001

с легаси в виде hstore. Индекс index_hstore был создан для запроса вида

SELECT "sometable"."id", "sometable"."col1", "sometable"."col2", "sometable"."col3", "sometable"."col4", "sometable"."hstore_col" FROM "sometable" WHERE (("sometable"."hstore_col" -> 'email') = 'randomemail' AND "sometable"."col4" = 'sometext') ORDER BY "sometable"."id" DESC LIMIT 100;

Однако, запрос его не использует (хотя раньше, при меньшем объеме данных, использовал). Я так и не дождался завершения этого запроса с analyze, он бежал больше 30 минут. Приложу просто explain

QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.58..168260.31 rows=100 width=259)
-> Index Scan Backward using sometable_pkey on sometable (cost=0.58..336916555.35 rows=200236 width=259)
Filter: (((col4)::text = 'sometext'::text) AND ((hstore_col -> 'email'::text) = 'randomemail'::text))
Settings: effective_cache_size = '32GB', jit = 'off', max_parallel_workers_per_gather = '0', random_page_cost = '1.1', work_mem = '64MB'

После того, как делаю индекс первичного ключа невалидным, запрос идет по нужному плану (дальше будут ссылки на сенд-кодер)
https://send-code.ru/paste/jimxhAEg
и если прогнать с analyze, то запрос выполняется моментально
https://send-code.ru/paste/mkoLlUgl
Проблема в том, что фактически строк с заданным email в таблице 0, когда оптимизатор ожидает их примерно 200236. Попробовал сделать n_distinct проблемной колонке -1

alter table sometable alter COLUMN hstore_col set (n_distinct = -1);

не помогло. Вероятно, связано с типом поля типа hstore. Увеличение stastic_target также не помогает. Единственный костыль, который помогает, снижение random_page_cost до 0.3, что в целом на уровне данной транзакции можно сделать, но в какой-то момент тоже может вылиться в проблемы. Есть ли у кого идеи, как победить планировщик?) Варианты с изменением типа поля на jsonb или вынос email в отдельное поле не предлагать)