PostgreSQL peut-il indexer les colonnes de tableaux?

Je ne trouve pas de réponse définitive à cette question dans la documentation. Si une colonne est de type tableau, toutes les valeurs entrées seront-elles indexées individuellement?

J'ai créé une table simple avec une int[]colonne et y ai mis un index unique. J'ai remarqué que je ne pouvais pas ajouter le même tableau d'entiers, ce qui me porte à croire que l'index est un composite des éléments du tableau, pas un index de chaque élément.

INSERT INTO "Test"."Test" VALUES ('{10, 15, 20}');
INSERT INTO "Test"."Test" VALUES ('{10, 20, 30}');

SELECT * FROM "Test"."Test" WHERE 20 = ANY ("Column1");

L'index aide-t-il cette requête?

Oui, vous pouvez indexer un tableau, mais vous devez utiliser les opérateurs de tableau et le type d'index GIN .

Exemple:

    CREATE TABLE "Test"("Column1" int[]);
    INSERT INTO "Test" VALUES ('{10, 15, 20}');
    INSERT INTO "Test" VALUES ('{10, 20, 30}');

    CREATE INDEX idx_test on "Test" USING GIN ("Column1");

    -- To enforce index usage because we have only 2 records for this test... 
    SET enable_seqscan TO off;

    EXPLAIN ANALYZE
    SELECT * FROM "Test" WHERE "Column1" @> ARRAY[20];

Résultat:

Bitmap Heap Scan on "Test"  (cost=4.26..8.27 rows=1 width=32) (actual time=0.014..0.015 rows=2 loops=1)
  Recheck Cond: ("Column1" @> '{20}'::integer[])
  ->  Bitmap Index Scan on idx_test  (cost=0.00..4.26 rows=1 width=0) (actual time=0.009..0.009 rows=2 loops=1)
        Index Cond: ("Column1" @> '{20}'::integer[])
Total runtime: 0.062 ms

il semble que dans de nombreux cas, l' option gin__int_ops soit requise

create index <index_name> on <table_name> using GIN (<column> gin__int_ops)

Je n'ai pas encore vu de cas où cela fonctionnerait avec l'opérateur && et @> sans les options gin__int_ops

@Tregoreg a soulevé une question dans le commentaire sur sa prime offerte:

Je n'ai pas trouvé les réponses actuelles fonctionnelles. L'utilisation de l'index GIN sur une colonne de type tableau n'augmente pas les performances de l'opérateur ANY (). N'y a-t-il vraiment pas de solution?

@ La réponse acceptée de Frank vous indique d'utiliser des opérateurs de tableau , ce qui est toujours correct pour Postgres 11. Le manuel:

... la distribution standard de PostgreSQL inclut une classe d'opérateurs GIN pour les tableaux, qui prend en charge les requêtes indexées à l'aide de ces opérateurs:

<@
@>
=
&&

La liste complète des classes d'opérateurs intégrées pour les index GIN dans la distribution standard se trouve ici.

Dans Postgres, les index sont liés à des opérateurs (qui sont implémentés pour certains types), pas à des types de données seuls ou à des fonctions ou autre. C'est un héritage de la conception Berkeley originale de Postgres et il est très difficile de changer maintenant. Et cela fonctionne généralement très bien. Voici un fil de discussion sur pgsql-bugs avec Tom Lane commentant cela.

_{Certaines fonctions PostGis (comme ST_DWithin()) semblent enfreindre ce principe, mais ce n'est pas le cas. Ces fonctions sont réécrites en interne pour utiliser les opérateurs respectifs .}

L'expression indexée doit être à gauche de l'opérateur. Pour la plupart des opérateurs ( y compris tout ce qui précède ), le planificateur de requêtes peut y parvenir en inversant les opérandes si vous placez l'expression indexée à droite - étant donné que a COMMUTATORa été défini. La ANYconstruction peut être utilisée en combinaison avec divers opérateurs et n'est pas un opérateur en soi. Lorsqu'ils sont utilisés comme constant = ANY (array_expression)seuls index prenant en charge l' =opérateur sur les éléments du tableau, ils sont qualifiés et nous aurions besoin d'un commutateur pour = ANY(). Les index GIN sont sortis.

Postgres n'est actuellement pas assez intelligent pour en dériver une expression indexable GIN. Pour commencer, constant = ANY (array_expression)n'est pas complètement équivalent à array_expression @> ARRAY[constant]. Les opérateurs de tableau renvoient une erreur si des éléments NULL sont impliqués, tandis que la ANYconstruction peut traiter NULL de chaque côté. Et il existe différents résultats pour les incohérences de types de données.

Réponses connexes:

• Vérifier si la valeur existe dans le tableau Postgres

• Index de recherche d'un élément dans un tableau JSON

• SQLAlchemy: comment filtrer sur les types de colonnes PgArray?

• IS DISTINCT FROM peut-il être combiné avec ANY ou ALL?

À part

Lorsque vous travaillez avec des integertableaux ( int4, pas int2ou int8) sans NULLvaleurs (comme votre exemple l'indique), considérez le module supplémentaire intarray, qui fournit des opérateurs spécialisés et plus rapides et un support d'index. Voir:

• Comment créer un index pour les éléments d'un tableau dans PostgreSQL?
• Comparer les tableaux pour l'égalité, en ignorant l'ordre des éléments

Quant à la UNIQUEcontrainte dans votre question qui est restée sans réponse: elle est implémentée avec un index btree sur toute la valeur du tableau (comme vous le soupçonniez) et n'aide pas du tout à la recherche d' éléments . Détails:

• Comment PostgreSQL applique-t-il la contrainte UNIQUE / quel type d'index utilise-t-il?

Il est maintenant possible d'indexer les éléments individuels du tableau. Par exemple:

CREATE TABLE test (foo int[]);
INSERT INTO test VALUES ('{1,2,3}');
INSERT INTO test VALUES ('{4,5,6}');
CREATE INDEX test_index on test ((foo[1]));
SET enable_seqscan TO off;

EXPLAIN ANALYZE SELECT * from test WHERE foo[1]=1;
                                                QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Index Scan using test_index on test  (cost=0.00..8.27 rows=1 width=32) (actual   time=0.070..0.071 rows=1 loops=1)
   Index Cond: (foo[1] = 1)
 Total runtime: 0.112 ms
(3 rows)

Cela fonctionne au moins sur Postgres 9.2.1. Notez que vous devez créer un index distinct pour chaque index de tableau, dans mon exemple, je n'ai indexé que le premier élément.