create table test(
    id serial primary key,
    tagged smallint[]
);

Hay un índice de ginebra entagged columna, con_int2_ops clase de operador:

CREATE INDEX ix ON test USING GIN(col _int2_ops);

Cuando ejecuto esta consulta:

select * from test
where tagged @> ARRAY[11]
order by id limit 100;

EXPLAIN ANALYZE muestra:

Limit  (cost=0.43..19524.39 rows=100 width=36) (actual time=25024.124..25027.263 rows=100 loops=1)
  ->  Index Scan using test_pkey on test  (cost=0.43..508404.37 rows=2604 width=36) (actual time=25024.121..25027.251 rows=100 loops=1)
        Filter: ((tagged)::integer[] @> '{11}'::integer[])
        Rows Removed by Filter: 2399999
Planning time: 6.912 ms
Execution time: 25027.307 ms

El énfasis en negrita es mío. Porque es eltagged columna convertida ainteger[] ¿tipo? Creo que esta es la razón por la cual GIN no se usa el índice y la consulta se ejecuta lentamente.

Lo intentéWHERE tagged @> ARRAY[11]::smallint[] pero tengo este error:

operator is not unique: smallint[] @> smallint[]

Si hago lo mismo pero usotagged int[] y crear índice como

CREATE INDEX ix ON test USING GIN(tagged gin__int_ops);

entonces la consulta anterior usa el índice GIN:

"->  Bitmap Index Scan on ix  (cost=0.00..1575.53 rows=2604 width=0) (actual time=382.840..382.840 rows=2604480 loops=1)"
"   Index Cond: (tagged @> '{11}'::integer[])"

Esto es un poco más rápido que el anterior, pero toma un promedio de 10 segundos, aún demasiado lento. Quiero intentarlosmallint[] en lugar deint[], tal vez eso sea más rápido ...