Czy kolumny z tablicami indeksów PostgreSQL?

W dokumentacji nie mogę znaleźć jednoznacznej odpowiedzi na to pytanie. Jeśli kolumna jest typem tablicowym, czy wszystkie wprowadzone wartości będą indeksowane indywidualnie?

Stworzyłem prostą tabelę z jedną int[]kolumną i umieściłem na niej unikalny indeks. Zauważyłem, że nie mogłem dodać tej samej tablicy liczb int, co prowadzi mnie do przekonania, że ​​indeks jest złożeniem elementów tablicy, a nie indeksem każdego elementu.

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

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

Czy indeks pomaga w tym zapytaniu?

Tak, możesz indeksować tablicę, ale musisz użyć operatorów tablic i typu indeksu GIN .

Przykład:

    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];

Wynik:

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

wydaje się, że w wielu przypadkach opcja gin__int_ops jest wymagana

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

Nie widziałem jeszcze przypadku, w którym działałoby to z operatorem && i @> bez opcji gin__int_ops

@Tregoreg zadał pytanie w komentarzu do swojej oferowanej nagrody:

Obecne odpowiedzi nie działają. Użycie indeksu GIN w kolumnie typu tablicowego nie zwiększa wydajności operatora ANY (). Czy naprawdę nie ma rozwiązania?

Zaakceptowana odpowiedź @ Franka mówi, że należy używać operatorów tablicowych , co nadal jest poprawne dla Postgres 11. Podręcznik:

... standardowa dystrybucja PostgreSQL zawiera klasę operatora GIN dla tablic, która obsługuje indeksowane zapytania przy użyciu tych operatorów:

<@
@>
=
&&

Pełna lista wbudowanych klas operatorów dla indeksów GIN w standardowej dystrybucji znajduje się tutaj.

W Postgres indeksy są powiązane z operatorami (które są zaimplementowane dla pewnych typów), a nie z samymi typami danych, funkcjami czy czymkolwiek innym. To dziedzictwo oryginalnego projektu Postgres Berkeley i bardzo trudne do zmiany. I ogólnie działa dobrze. Tutaj jest wątek na temat pgsql-bugs z komentarzem Tom'a Lane'a.

_{Niektóre funkcje PostGis (takie jak ST_DWithin()) wydają się naruszać tę zasadę, ale tak nie jest. Te funkcje są przepisywane wewnętrznie, aby używać odpowiednich operatorów .}

Indeksowane wyrażenie musi znajdować się po lewej stronie operatora. W przypadku większości operatorów (w tym wszystkich powyższych ) planista zapytań może to osiągnąć, odwracając operandy, jeśli umieścisz indeksowane wyrażenie po prawej stronie - zakładając, że COMMUTATORzdefiniowano a. ANYKonstrukt może być stosowany w połączeniu z różnych operatorów i nie jest sama w sobie operatora. Gdy jest używany jako constant = ANY (array_expression)tylko indeksy obsługujące =operator na elementach tablicy , kwalifikowałby się i potrzebowalibyśmy komutatora = ANY(). Indeksy GIN są wyłączone.

Postgres nie jest obecnie wystarczająco inteligentny, aby wyprowadzić z niego wyrażenie indeksowalne GIN. Na początek nieconstant = ANY (array_expression) jest całkowicie równoważne z array_expression @> ARRAY[constant]. Operatory tablicowe zwracają błąd, jeśli zaangażowane są jakiekolwiek elementy NULL , podczas gdy ANYkonstrukcja może obsłużyć NULL po obu stronach. Istnieją różne wyniki dla niezgodności typów danych.

Powiązane odpowiedzi:

• Sprawdź, czy wartość istnieje w tablicy Postgres

• Indeks do znajdowania elementu w tablicy JSON

• SQLAlchemy: jak filtrować według typów kolumn PgArray?

• Czy JEST WYRÓŻNIONY OD JAKIEKOLWIEK lub WSZYSTKIE?

Poza tym

Podczas pracy z integertablicami ( int4nie int2lub int8) bez NULLwartości (jak sugeruje twój przykład) rozważ dodatkowy moduł intarray, który zapewnia wyspecjalizowane, szybsze operatory i obsługę indeksów. Widzieć:

• Jak stworzyć indeks dla elementów tablicy w PostgreSQL?
• Porównaj tablice pod kątem równości, ignorując kolejność elementów

Jeśli chodzi o UNIQUEograniczenie w twoim pytaniu, które pozostało bez odpowiedzi: jest zaimplementowane z indeksem btree na całej wartości tablicy (tak jak podejrzewasz) i wcale nie pomaga w wyszukiwaniu elementów . Detale:

• W jaki sposób PostgreSQL wymusza ograniczenie UNIQUE / jakiego typu indeksu używa?

Teraz można indeksować poszczególne elementy tablicy. Na przykład:

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)

Działa to przynajmniej na Postgres 9.2.1. Zauważ, że musisz zbudować oddzielny indeks dla każdego indeksu tablicy, w moim przykładzie zindeksowałem tylko pierwszy element.