デバッグの少し後に、外側のjson要素(「ルート」など)用に作成されたインデックスが、階層内のすべてのネストされた要素にも適用されることがわかりました。だから、私の場合は、正しい解決策は次のとおりです。
CREATE INDEX idx_tmp_data_root ON tmp USING gin ((data->'root') jsonb_path_ops);
それは必要に応じて@>
を照会封じ込めをサポートし、デフォルト・インデックス・タイプとは対照的に、よりコンパクトでより高速なインデックス内の結果以来、私はjsonb_path_ops
インデックス演算子クラスを選択しました。
そして、ここでは完全なデモンストレーションです:
まず、テーブルと負荷データの作成:インデックスと
-> explain select * from tmp where data->'root' @> '[{"name": "item1"}]';
QUERY PLAN
Seq Scan on tmp (cost=10000000000.00..10000000029.65 rows=1 width=32)
Filter: ((data -> 'root'::text) @> '[{"name": "item1"}]'::jsonb)
(2 rows)
クエリ:インデックスなし
-> SET enable_seqscan = OFF; -- force postgres to use indices if any
-> create temporary table tmp (data jsonb not null);
-> insert into tmp (data) values ('{"root": [{"name": "item1"}, {"name": "item2"}]}');
クエリ
を
-> CREATE INDEX idx_tmp_data_root ON tmp USING gin ((data->'root') jsonb_path_ops);
-> explain select * from tmp where data->'root' @> '[{"name": "item1"}]';
QUERY PLAN
Bitmap Heap Scan on tmp (cost=8.00..12.02 rows=1 width=32)
Recheck Cond: ((data -> 'root'::text) @> '[{"name": "item1"}]'::jsonb)
-> Bitmap Index Scan on idx_tmp_data_root (cost=0.00..8.00 rows=1 width=0)
Index Cond: ((data -> 'root'::text) @> '[{"name": "item1"}]'::jsonb)
(4 rows)
-> SET enable_seqscan = ON;
'CREATE INDEX ON tmp((dat a - >> 'root')); '? – Hackerman
@Hackermanあなたは閉じていました。正しい解決策は 'data - > 'root''のようです。 – user2740947