Может ли PostgreSQL индексировать столбцы массива?

Question 1

Я не могу найти однозначного ответа на этот вопрос в документации. Если столбец имеет тип массива, будут ли все введенные значения индексироваться индивидуально?

Я создал простую таблицу с одним int[]столбцом и поместил на нее уникальный индекс. Я заметил, что не могу добавить тот же массив целых чисел, что наводит меня на мысль, что индекс является составной частью элементов массива, а не индексом каждого элемента.

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

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

Помогает ли индекс этому запросу?

Question 2

Да, вы можете индексировать массив, но вы должны использовать операторы массива и тип индекса GIN .

Пример:

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

Результат:

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

Заметка

похоже, что во многих случаях требуется опция gin__int_ops

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

Я еще не видел случая, чтобы он работал с операторами && и @> без параметров gin__int_ops

Question 3

@Tregoreg поднял вопрос в комментарии к предложенной им награде:

Я не нашел, что текущие ответы работают. Использование индекса GIN для столбца с типом массива не увеличивает производительность оператора ANY (). Неужели решения нет?

В принятом ответе @Frank предлагается использовать операторы массива , что по- прежнему верно для Postgres 11. Руководство:

... стандартный дистрибутив PostgreSQL включает класс операторов GIN для массивов, который поддерживает индексированные запросы с использованием следующих операторов:
<@
@>
=
&&

Полный список классов встроенных операторов для индексов GIN в стандартной поставке находится здесь.

В Postgres индексы привязаны к операторам (которые реализованы для определенных типов), а не только к типам данных, функциям или чему-либо еще. Это наследие оригинального дизайна Postgres в Беркли, и сейчас его очень сложно изменить. И в целом работает нормально. Вот ветка pgsql-bugs, где Том Лейн комментирует это.

_{Некоторые функции PostGis (например, ST_DWithin()) нарушают этот принцип, но это не так. Эти функции внутренне переписаны для использования соответствующих операторов .}

Проиндексированное выражение должно находиться слева от оператора. Для большинства операторов ( включая все вышеперечисленные ) планировщик запросов может добиться этого, переворачивая операнды, если вы поместите индексированное выражение вправо - при условии, что COMMUTATORбыл определен a . ANYКонструкция может быть использована в комбинации с различными операторами и не является сам оператор. При использовании constant = ANY (array_expression)только индексы, поддерживающие =оператор для элементов массива, будут квалифицированы, и нам понадобится коммутатор для = ANY(). Индексы GIN отсутствуют.

Postgres в настоящее время недостаточно умен, чтобы получить из него выражение, индексируемое GIN. Во - первых, constant = ANY (array_expression)это не полностью эквивалентны с array_expression @> ARRAY[constant]. Операторы массива возвращают ошибку, если задействованы какие-либо элементы NULL , в то время как ANYконструкция может обрабатывать NULL с любой стороны. И есть разные результаты для несоответствия типов данных.

Связанные ответы:

В сторону

При работе с integerмассивами ( int4, не int2или int8) без NULLзначений (как предполагает ваш пример) рассмотрите дополнительный модуль intarray, который предоставляет специализированные, более быстрые операторы и поддержку индексов. Увидеть:

Что касается UNIQUEограничения в вашем вопросе, который остался без ответа: это реализовано с помощью индекса btree для всего значения массива (как вы и подозревали) и вообще не помогает с поиском элементов . Детали:

Как PostgreSQL обеспечивает соблюдение ограничения UNIQUE / какой тип индекса он использует?

Question 4

Теперь можно индексировать отдельные элементы массива. Например:

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)

Это работает как минимум на Postgres 9.2.1. Обратите внимание, что вам нужно создать отдельный индекс для каждого индекса массива, в моем примере я проиндексировал только первый элемент.