Чи може PostgreSQL індексувати стовпці?

Я не можу знайти однозначної відповіді на це питання в документації. Якщо стовпець - це тип масиву, чи всі введені значення будуть індексуватися індивідуально?

Я створив просту таблицю з одним int[]стовпцем і поставив на ній унікальний індекс. Я помітив, що не можу додати той самий масив ints, що змушує мене вважати, що індекс - це складова елементів масиву, а не індекс кожного елемента.

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

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

Чи допомагає індекс у цьому запиті?

Так, ви можете проіндексувати масив, але вам доведеться використовувати оператори масиву та тип індексу 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

@Tregoreg поставив запитання в коментарі до запропонованої йому винагороди:

Я не знайшов діючих відповідей. Використання індексу GIN на стовпчику масиву не збільшує продуктивність оператора ANY (). Невже немає рішення?

@ Прийнята відповідь Франка говорить про використання операторів масиву , що все ще правильно для Postgres 11. Посібник:

... стандартний розподіл PostgreSQL включає клас операторів GIN для масивів, який підтримує індексовані запити за допомогою цих операторів:

<@
@>
=
&&

Повний список вбудованих операторських класів для GIN-індексів у стандартній дистрибуції тут.

У Postgres індекси пов'язані з операторами (які реалізовані для певних типів), а не типами даних або функціями чи чим-небудь іншим. Це спадщина оригінального дизайну Bergley Postgres і зараз дуже важко змінити. І це, як правило, працює просто чудово. Ось нитка про pgsql-помилок, коментуючи це, коментує Том Лейн.

_{Деякі функції PostGis (наприклад,ST_DWithin() ), здається, порушують цю головну, але це не так. Ці функції переписані внутрішньо для використання відповідних операторів .}

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

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

Відповідні відповіді:

• Перевірте, чи існує значення в масиві Postgres

• Індекс для пошуку елемента в масиві JSON

• SQLAlchemy: як відфільтрувати типи стовпців PgArray?

• Чи можна ВІДДІЛИТИ ВІД ЧАСУВАННЯ З будь-яким чи ВСІМ?

Убік

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

• Як створити індекс для елементів масиву в PostgreSQL?
• Порівняйте масиви для рівності, ігноруючи порядок елементів

Що стосується UNIQUEобмеження у вашому запитанні, яке не залишилося без відповіді: це реалізовано з btree індексом для всього значення масиву (як ви підозрювали) і зовсім не допомагає шукати елементи . Деталі:

• Як PostgreSQL застосовує обмеження UNIQUE / який тип індексу він використовує?

Тепер можна індексувати окремі елементи масиву. Наприклад:

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. Зауважте, що вам потрібно створити окремий індекс для кожного індексу масиву, у моєму прикладі я індексував лише перший елемент.