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

Es gibt einen Gin-Index fürtagged Spalte, mit_int2_ops Bedienerklasse:

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

Wenn ich diese Abfrage starte:

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

EXPLAIN ANALYZE zeigt an

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

Fettdruck meine. Warum ist dertagged Spalte konvertiert zuinteger[] Art? Ich denke, dies ist der Grund, warum GIN der Index nicht verwendet wird und die Abfrage langsam läuft.

Ich habe es versuchtWHERE tagged @> ARRAY[11]::smallint[] bekam aber diesen Fehler:

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

Wenn ich dasselbe mache, aber @ benuttagged int[] und erstelle einen Index als

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

dann verwendet die obige Abfrage den GIN-Index:

"->  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[])"

Dies ist etwas schneller als vorher, aber es dauert durchschnittlich 10 Sekunden - immer noch zu langsam. Ich möchte es versuchensmallint[] Anstatt vonint[], vielleicht geht das schneller ...