Postgres и индексы на внешних ключах и первичных ключах

Postgres автоматически помещает индексы на внешние ключи и первичные ключи? Как я могу сказать? Есть ли команда, которая вернет все индексы в таблице?

6 ответов


PostgreSQL автоматически создает индексы на первичных ключах и уникальных ограничениях, но не на ссылочной стороне отношений внешнего ключа.

когда Pg создает неявный индекс, он выдает NOTICE - сообщение уровня, которое вы можете увидеть в psql и / или системные журналы, чтобы вы могли видеть, когда это произойдет. Автоматически созданные индексы отображаются в \d вывод для таблицы тоже.

на документация по уникальным индексам говорит:

PostgreSQL автоматически создает индекс для каждого уникального ограничения и ограничения первичного ключа для обеспечения уникальности. Таким образом, нет необходимости создавать индекс явно для столбцов первичного ключа.

и документация на ограничения говорит:

С момента удаления строки из ссылочной таблицы или обновления ссылочный столбец потребует сканирования ссылочной таблицы для строки сопоставляя старое значение, часто рекомендуется индексировать ссылочный столбец. Потому что это не всегда нужно, а есть доступно множество вариантов индексирования, объявления внешнего ключа ограничение не создает автоматически индекс для ссылки столбцы.

поэтому вам нужно создать индексы на внешних ключах самостоятельно, если вы хотите их.

обратите внимание, что если вы используете первичные внешние ключи, например 2 FK в качестве PK в таблице M-To-N, вы будет иметь индекс на ПК и, вероятно, не нужно создавать никаких дополнительных индексов.

хотя обычно рекомендуется создавать индекс (или включать) столбцы внешнего ключа на стороне ссылки, это не требуется. Каждый добавленный индекс немного замедляет операции DML, поэтому вы платите стоимость производительности за каждый INSERT, UPDATE или DELETE. Если индекс редко используется, он может не стоить того.


Если вы хотите перечислить индексы всех таблиц в вашей схеме(схемах) из вашей программы, вся информация находится под рукой в каталоге:

select
     n.nspname  as "Schema"
    ,t.relname  as "Table"
    ,c.relname  as "Index"
from
          pg_catalog.pg_class c
     join pg_catalog.pg_namespace n on n.oid        = c.relnamespace
     join pg_catalog.pg_index i     on i.indexrelid = c.oid
     join pg_catalog.pg_class t     on i.indrelid   = t.oid
where
        c.relkind = 'i'
    and n.nspname not in ('pg_catalog', 'pg_toast')
    and pg_catalog.pg_table_is_visible(c.oid)
order by
     n.nspname
    ,t.relname
    ,c.relname

Если вы хотите углубиться дальше (например, столбцы и порядок), вам нужно посмотреть на pg_catalog.pg_index. Использование psql -E [dbname] пригодится для выяснения того, как запросить каталог.


Да-для первичных ключей, нет-для внешних ключей (подробнее в docs).

\d <table_name>

на "psql" показывает описание таблицы, включая все его индексы.


этот запрос будет список отсутствующих индексов на внешние ключи, первоисточник.

-- check for FKs where there is no matching index
-- on the referencing side
-- or a bad index

WITH fk_actions ( code, action ) AS (
    VALUES ( 'a', 'error' ),
        ( 'r', 'restrict' ),
        ( 'c', 'cascade' ),
        ( 'n', 'set null' ),
        ( 'd', 'set default' )
),
fk_list AS (
    SELECT pg_constraint.oid as fkoid, conrelid, confrelid as parentid,
        conname, relname, nspname,
        fk_actions_update.action as update_action,
        fk_actions_delete.action as delete_action,
        conkey as key_cols
    FROM pg_constraint
        JOIN pg_class ON conrelid = pg_class.oid
        JOIN pg_namespace ON pg_class.relnamespace = pg_namespace.oid
        JOIN fk_actions AS fk_actions_update ON confupdtype = fk_actions_update.code
        JOIN fk_actions AS fk_actions_delete ON confdeltype = fk_actions_delete.code
    WHERE contype = 'f'
),
fk_attributes AS (
    SELECT fkoid, conrelid, attname, attnum
    FROM fk_list
        JOIN pg_attribute
            ON conrelid = attrelid
            AND attnum = ANY( key_cols )
    ORDER BY fkoid, attnum
),
fk_cols_list AS (
    SELECT fkoid, array_agg(attname) as cols_list
    FROM fk_attributes
    GROUP BY fkoid
),
index_list AS (
    SELECT indexrelid as indexid,
        pg_class.relname as indexname,
        indrelid,
        indkey,
        indpred is not null as has_predicate,
        pg_get_indexdef(indexrelid) as indexdef
    FROM pg_index
        JOIN pg_class ON indexrelid = pg_class.oid
    WHERE indisvalid
),
fk_index_match AS (
    SELECT fk_list.*,
        indexid,
        indexname,
        indkey::int[] as indexatts,
        has_predicate,
        indexdef,
        array_length(key_cols, 1) as fk_colcount,
        array_length(indkey,1) as index_colcount,
        round(pg_relation_size(conrelid)/(1024^2)::numeric) as table_mb,
        cols_list
    FROM fk_list
        JOIN fk_cols_list USING (fkoid)
        LEFT OUTER JOIN index_list
            ON conrelid = indrelid
            AND (indkey::int2[])[0:(array_length(key_cols,1) -1)] @> key_cols

),
fk_perfect_match AS (
    SELECT fkoid
    FROM fk_index_match
    WHERE (index_colcount - 1) <= fk_colcount
        AND NOT has_predicate
        AND indexdef LIKE '%USING btree%'
),
fk_index_check AS (
    SELECT 'no index' as issue, *, 1 as issue_sort
    FROM fk_index_match
    WHERE indexid IS NULL
    UNION ALL
    SELECT 'questionable index' as issue, *, 2
    FROM fk_index_match
    WHERE indexid IS NOT NULL
        AND fkoid NOT IN (
            SELECT fkoid
            FROM fk_perfect_match)
),
parent_table_stats AS (
    SELECT fkoid, tabstats.relname as parent_name,
        (n_tup_ins + n_tup_upd + n_tup_del + n_tup_hot_upd) as parent_writes,
        round(pg_relation_size(parentid)/(1024^2)::numeric) as parent_mb
    FROM pg_stat_user_tables AS tabstats
        JOIN fk_list
            ON relid = parentid
),
fk_table_stats AS (
    SELECT fkoid,
        (n_tup_ins + n_tup_upd + n_tup_del + n_tup_hot_upd) as writes,
        seq_scan as table_scans
    FROM pg_stat_user_tables AS tabstats
        JOIN fk_list
            ON relid = conrelid
)
SELECT nspname as schema_name,
    relname as table_name,
    conname as fk_name,
    issue,
    table_mb,
    writes,
    table_scans,
    parent_name,
    parent_mb,
    parent_writes,
    cols_list,
    indexdef
FROM fk_index_check
    JOIN parent_table_stats USING (fkoid)
    JOIN fk_table_stats USING (fkoid)
WHERE table_mb > 9
    AND ( writes > 1000
        OR parent_writes > 1000
        OR parent_mb > 10 )
ORDER BY issue_sort, table_mb DESC, table_name, fk_name;

Мне нравится, как это описано в статье классные характеристики производительности EclipseLink 2.5

Индексирование Внешних Ключей

первая функция-автоматическая индексация внешних ключей. Большинство людей ошибочно полагают, что индекс баз данных внешние ключи по умолчанию. Ну, это не так. Первичные ключи автоматические индексируются, но внешние ключи-нет. Это означает любой запрос, основанный на внешний ключ будет выполнять полное сканирование таблицы. Это любой OneToMany, ManyToMany или ElementCollection отношения, а также много OneToOne отношения, и большинство запросов о любых отношениях, связанных с соединениями или сравнение объектов. Это может быть серьезной проблемой perform, и вы должны всегда индексируйте поля внешних ключей.


на PRIMARY KEY, индекс будет создан со следующим сообщением:

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "index" for table "table" 

на FOREIGN KEY, ограничение не будет создано, если на referencЭд таблица.

индекс на referencing таблица не требуется (хотя и желательна), и поэтому не будет неявно создана.