строк
— в таблице jsonb поле
— по этому полю построен GIN индекс
Проблема — планироващик выбирает Seq scan или Index scan, смотря на значение LIMIT в запросе
- LIMIT 10 — Seq scan
- LIMIT 100 — Index scan
Знаю про принудительное отключение секс скана, но хотелось бы как-то избежать, если возможно?
у нас тут холивар, сори, по вопросам заходи завтра
А чем тебе секс кан не люб?
Медленнее работает, чем индекс скан
Сильно медленнее ?
Покажите 1) версию PostgreSQL, 2) запрос, 3) \d каждой используемой таблицы, 4) EXPLAIN (ANALYZE, BUFFERS). Если действительно хотите — покажите все 4 (четыре), и именно те, которые указаны в пунктах. ;)
LIMIT 10 — 6.5 секунд LIMIT 100 —13 мс
Ты ничего не перепутал? Точно ? Странно просто.
А сортировка есть?
Нет. Но если добавить order by random(), тоже быстро работает
1. Работаем на 13 PG 2. SELECT * FROM "careplan" WHERE "careplan".resource @> '{"subject":{"id":"a71ccbb0-2c3f-ed8d-cd74-1bc2b3ff0a1f","resourceType":"Patient"}}' 3. Fields careplan id text careplan txid bigint careplan cts timestamp with time zone careplan ts timestamp with time zone careplan resource_type text careplan status USER-DEFINED careplan resource jsonb Indexes careplan careplan_pt1_btree CREATE INDEX careplan_pt1_btree ON public.careplan USING btree (((resource #>> '{subject,id}'::text[]))) careplan careplan_pkey CREATE UNIQUE INDEX careplan_pkey ON public.careplan USING btree (id) careplan careplan_txid_btree CREATE INDEX careplan_txid_btree ON public.careplan USING btree (txid) careplan careplan_jsonb_gin CREATE INDEX careplan_jsonb_gin ON public.careplan USING gin (resource jsonb_path_ops) 4. Explain analyze https://t.me/pgsql/356974 ЛИМИТ 10 - работает 6 секунд explain (analyze, buffers) SELECT * FROM "careplan" WHERE "careplan".resource @> '{"subject":{"id":"a71ccbb0-2c3f-ed8d-cd74-1bc2b3ff0a1f","resourceType":"Patient"}}' LIMIT 10 даёт Limit (cost=0.00..277.69 rows=10 width=1973) (actual time=0.018..6064.989 rows=3 loops=1) -> Seq Scan on careplan (cost=0.00..1919961.85 rows=69141 width=1973) (actual time=0.017..6064.985 rows=3 loops=1) Filter: (resource @> '{"subject": {"id": "a71ccbb0-2c3f-ed8d-cd74-1bc2b3ff0a1f", "resourceType": "Patient"}}'::jsonb) Rows Removed by Filter: 6914065 Planning Time: 0.794 ms Execution Time: 6065.013 ms Лимит 100 - доли секунды explain (analyze, buffers) SELECT * FROM "careplan" WHERE "careplan".resource @> '{"subject":{"id":"a71ccbb0-2c3f-ed8d-cd74-1bc2b3ff0a1f","resourceType":"Patient"}}' LIMIT 100 даёт Limit (cost=687.84..1089.04 rows=100 width=1973) (actual time=0.083..0.087 rows=3 loops=1) -> Bitmap Heap Scan on careplan (cost=687.84..278080.27 rows=69141 width=1973) (actual time=0.082..0.085 rows=3 loops=1) Recheck Cond: (resource @> '{"subject": {"id": "a71ccbb0-2c3f-ed8d-cd74-1bc2b3ff0a1f", "resourceType": "Patient"}}'::jsonb) Heap Blocks: exact=2 -> Bitmap Index Scan on careplan_jsonb_gin (cost=0.00..670.56 rows=69141 width=0) (actual time=0.071..0.071 rows=3 loops=1) Index Cond: (resource @> '{"subject": {"id": "a71ccbb0-2c3f-ed8d-cd74-1bc2b3ff0a1f", "resourceType": "Patient"}}'::jsonb) Planning Time: 0.795 ms Execution Time: 0.129 ms
Обсуждают сегодня