PostgreSQL不使用GIN索引进行查询

我使用了一个查询（因为性能更好，所以使用了OR块而不是大查询）：

解释分析查询：

Gather  (cost=1000.00..89666.80 rows=207290 width=139) (actual time=2.431..6942.170 rows=76101 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  ->  Parallel Seq Scan on products p  (cost=0.00..67937.80 rows=86371 width=139) (actual time=0.586..6853.961 rows=25367 loops=3)
        Filter: ((description && '{791,11705,22921,29515,36965,41021,47203,49459,54602,60499}'::integer[]) OR (description && '{62033,73399,75438,76195,78038,79370,82347,85446,85633,92320}'::integer[]) OR (description && '{94803,95210,103635,104413,110362,114901,115482,118053,144377,144592}'::integer[]) OR ...
        Rows Removed by Filter: 61185
Planning time: 1.918 ms
Execution time: 6950.584 ms

并用ENABLE_SEQSCAN=FALSE解释分析；选项：

Gather  (cost=19139.18..107805.98 rows=207290 width=139) (actual time=512.903..571.331 rows=76101 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  ->  Parallel Bitmap Heap Scan on products p  (cost=18139.18..86076.98 rows=86371 width=139) (actual time=502.441..517.985 rows=25367 loops=3)
        Recheck Cond: ((description && '{791,11705,22921,29515,36965,41021,47203,49459,54602,60499}'::integer[]) OR (description && '{62033,73399,75438,76195,78038,79370,82347,85446,85633,92320}'::integer[]) OR (description && '{94803,95210,103635,104413,110362,114901,115482,118053,144377,144592}'::integer[]) OR (description && '{162314,174062,177685,179717,181979,196348,201003,213047,223458,231169}'::integer[]) OR (description && '{237073,242931,244061,245314,246673,257988,260198,260664,263250,263957}'::integer[]) OR (description && '{271730,271817,273768,275097,279056,288771,289375,294934,304523,311319}'::integer[]) OR (description && '{312113,322217,322889,324356,325774,326251,338673,347436,347467,349276}'::integer[]) OR (description && '{352233,353920,356966,364539,364601,385678,394335,396345,404511,409874}'::integer[]) OR (description && '{423310,441817,445483,453401,460896,461693,462106,466680,474877,478839}'::integer[]) OR (description && '{484941,489442,489946,490523,490883,494463,496539,497198,503385,507944}'::integer[]) OR (description && '{512199,529380,529715,533907,534796,547913,551711,570389,574545,582169}'::integer[]) OR (description && '{586486,591756,597798,598733,601138,604477,606417,607399,609051,612431}'::integer[]) OR (description && '{627519,632265,642944,644396,652624,657323,660675,674114,680471,694340}'::integer[]) OR (description && '{696385,9709,41582,114552,279064,325285,342008,351284,628528,653153}'::integer[]) OR (description && '{656846,4316,10946,22093,24018,27702,33375,46878,65895,77003}'::integer[]) OR (description && '{95393,114783,118457,141371,150094,152895,162732,163157,163367,203877}'::integer[]) OR (description && '{210856,217923,241203,249221,253779,267201,272252,273653,278116,293802}'::integer[]) OR (description && '{295701,300599,302252,326873,358918,363728,383700,384585,424374,438758}'::integer[]) OR (description && '{447823,462266,470243,478988,480508,505702,509906,515737,564044,564152}'::integer[]) OR ...)
        Heap Blocks: exact=91
        ->  BitmapOr  (cost=18139.18..18139.18 rows=259656 width=0) (actual time=504.150..504.150 rows=0 loops=1)
              ->  Bitmap Index Scan on products_gin_index  (cost=0.00..157.01 rows=3869 width=0) (actual time=39.016..39.016 rows=0 loops=1)
                    Index Cond: (description && '{791,11705,22921,29515,36965,41021,47203,49459,54602,60499}'::integer[])
              ->  Bitmap Index Scan on products_gin_index  (cost=0.00..157.01 rows=3869 width=0) (actual time=10.940..10.940 rows=0 loops=1)
                    Index Cond: (description && '{62033,73399,75438,76195,78038,79370,82347,85446,85633,92320}'::integer[])
              ->  Bitmap Index Scan on products_gin_index  (cost=0.00..157.01 rows=3869 width=0) (actual time=10.610..10.610 rows=0 loops=1)
                    Index Cond: (description && '{94803,95210,103635,104413,110362,114901,115482,118053,144377,144592}'::integer[])
              ->  Bitmap Index Scan on products_gin_index  (cost=0.00..157.01 rows=3869 width=0) (actual time=11.452..11.452 rows=0 loops=1)
                    Index Cond: (description && '{162314,174062,177685,179717,181979,196348,201003,213047,223458,231169}'::integer[])
              ->  Bitmap Index Scan on products_gin_index  (cost=0.00..157.01 rows=3869 width=0) (actual time=3.429..3.429 rows=0 loops=1)
                    Index Cond: (description && '{237073,242931,244061,245314,246673,257988,260198,260664,263250,263957}'::integer[])
              ->  Bitmap Index Scan on products_gin_index  (cost=0.00..157.01 rows=3869 width=0) (actual time=2.290..2.290 rows=0 loops=1)
                    ...
Planning time: 1.378 ms
Execution time: 581.867 ms

正如您所看到的，尽管有计划的成本，第二次查询速度要快得多。 该查询是较大查询（如CTE）的一部分，因此我无法对整个查询禁用顺序扫描

有一个产品栏：

prepared_description INT4[]

和它的GIN索引：

CREATE INDEX products_gin_index ON products USING GIN(description gin__int_ops);

表有约300000行，在描述数组中平均为21.6整数

---

有没有办法强制在此查询上使用索引？

您是否对该表运行了

analyze

？可能您需要对该列进行更精确的统计

ALTER TABLE products ALTER column description SET statistics 1000

statistics稍微更改了成本（增加了成本，有索引和没有索引）-问题仍然存在。估计的行数是否更接近实际数？在最初的计划中，研究生们似乎很难得到正确的估计。您是否尝试对所有您比较的

description

数组进行压缩，并只执行一个

&

？结果是一样的。结果更糟；）<代码>准备描述pd时的顺序扫描（成本=0.00..47381.70行=189000宽度=139）（实际时间=0.199..19112.194行=76101循环=1）

CREATE INDEX products_gin_index ON products USING GIN(description gin__int_ops);