Индексирование массива строк типа столбца в PostgreSql

Question

Можно создать индекс для столбца, тип которого массив строк .Пробовал с использованием индексов GIN .Но запросы, похоже, не используют эти индексы.

Example

CREATE TABLE users (
 name VARCHAR(100),
 groups text[],
);

Query: SELECT name FROM users WHERE ANY(groups) = 'Engineering'.

Также, каков наилучший способ эффективного выполнения GROUP BY для столбца 'groups', чтобы он мог давать 'groups' и count.

Answer 1

Можно использовать индекс джина:

CREATE TABLE users (
 name VARCHAR(100),
 groups text[]
);

CREATE INDEX idx_users ON users USING GIN(groups);

-- disable sequential scan in this test:
SET enable_seqscan TO off;

EXPLAIN ANALYZE
SELECT name FROM users WHERE  groups @> (ARRAY['Engineering']);

Результат:

"Bitmap Heap Scan on users  (cost=4.26..8.27 rows=1 width=218) (actual time=0.021..0.021 rows=0 loops=1)"
"  Recheck Cond: (groups @> '{Engineering}'::text[])"
"  ->  Bitmap Index Scan on idx_users  (cost=0.00..4.26 rows=1 width=0) (actual time=0.016..0.016 rows=0 loops=1)"
"        Index Cond: (groups @> '{Engineering}'::text[])"
"Total runtime: 0.074 ms"

Использование агрегатных функций в массиве, это будет еще одной проблемой. Может помочь функция unnest ().

Почему вы не нормализуете свои данные? Это исправит все проблемы, в том числе многие проблемы, с которыми вы еще не сталкивались.

Answer 2

Я думаю, что лучший способ справиться с этим - нормализовать вашу модель. Следующее, вероятно, будет содержать ошибки, поскольку я не пробовал, но идея должна быть ясна:

CREATE TABLE users (id INTEGER PRIMARY KEY, name VARCHAR(100) UNIQUE);
CREATE TABLE groups (id INTEGER PRIMARY KEY, name VARCHAR(100) UNIQUE);
CREATE TABLE user_group (
    user INTEGER NOT NULL REFERENCES users,
    group INTEGER NOT NULL REFERENCES groups);
CREATE UNIQUE INDEX user_group_unique ON user_group (user, group);

SELECT users.name
    FROM user_group
    INNER JOIN users ON user_group.user = users.id
    INNER JOIN groups ON user_group.group = groups.id
    WHERE groups.name = 'Engineering';

Полученный план выполнения уже должен быть достаточно эффективным; вы все еще можете оптимизировать, индексируя ON user_group (group), что позволяет index_scan, а не sequential_scan, найти членов определенной группы.