Postgres place-t-il automatiquement des index sur les clés étrangères et les clés primaires? Comment savoir? Existe-t-il une commande qui retournera tous les index d'une table?
Postgres place-t-il automatiquement des index sur les clés étrangères et les clés primaires? Comment savoir? Existe-t-il une commande qui retournera tous les index d'une table?
Réponses:
PostgreSQL crée automatiquement des index sur les clés primaires et les contraintes uniques, mais pas sur le côté de référencement des relations de clés étrangères.
Lorsque Pg crée un index implicite, il émet un NOTICE
message de niveau que vous pouvez voir dans psql
et / ou les journaux système, afin que vous puissiez voir quand cela se produit. Les index créés automatiquement sont également visibles dans la \d
sortie d'une table.
La documentation sur les index uniques indique:
PostgreSQL crée automatiquement un index pour chaque contrainte unique et contrainte de clé primaire pour renforcer l'unicité. Ainsi, il n'est pas nécessaire de créer un index explicitement pour les colonnes de clé primaire.
et la documentation sur les contraintes dit:
Étant donné que la suppression d'une ligne de la table référencée ou la mise à jour d'une colonne référencée nécessitera une analyse de la table de référence pour les lignes correspondant à l'ancienne valeur, il est souvent judicieux d'indexer les colonnes de référence. Étant donné que cela n'est pas toujours nécessaire et qu'il existe de nombreux choix disponibles sur la façon d'indexer, la déclaration d'une contrainte de clé étrangère ne crée pas automatiquement un index sur les colonnes de référence.
Par conséquent, vous devez créer vous-même des index sur les clés étrangères.
Notez que si vous utilisez des clés étrangères primaires, comme 2 FK en tant que PK dans une table M-to-N, vous aurez un index sur le PK et vous n'aurez probablement pas besoin de créer d'index supplémentaires.
Bien que ce soit généralement une bonne idée de créer un index sur (ou incluant) vos colonnes de clé étrangère côté référencement, ce n'est pas obligatoire. Chaque index que vous ajoutez ralentit légèrement les opérations DML, vous payez donc un coût de performance pour chaque INSERT
, UPDATE
ou DELETE
. Si l'index est rarement utilisé, cela ne vaut peut-être pas la peine.
Si vous souhaitez lister les index de toutes les tables de vos schémas de votre programme, toutes les informations sont à portée de main dans le catalogue:
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
Si vous souhaitez approfondir (comme les colonnes et la commande), vous devez regarder pg_catalog.pg_index. L'utilisation psql -E [dbname]
est utile pour déterminer comment interroger le catalogue.
\di
, tous les index de la base de données seront également répertoriés." (le commentaire copié de l'autre réponse s'applique ici également)
Cette requête répertorie les index manquants sur les clés étrangères , source d'origine .
Edit : Notez qu'il ne vérifiera pas les petites tables (moins de 9 Mo) et certains autres cas. Voir WHERE
déclaration finale .
-- 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;
where
clauses: Entre autres, il ne prend en compte que les tableaux dont la taille est supérieure à 9 Mo.
Oui - pour les clés primaires, non - pour les clés étrangères (plus dans la documentation ).
\d <table_name>
dans "psql" montre une description d'une table incluant tous ses index.
J'adore la façon dont cela est expliqué dans l'article Fonctionnalités de performances intéressantes d'EclipseLink 2.5
Indexation des clés étrangères
La première fonctionnalité est l'indexation automatique des clés étrangères. La plupart des gens supposent à tort que les bases de données indexent les clés étrangères par défaut. Eh bien, non. Les clés primaires sont indexées automatiquement, mais pas les clés étrangères. Cela signifie que toute requête basée sur la clé étrangère effectuera des analyses complètes de table. Ceci est tout OneToMany , ManyToMany ou ElementCollection relation, ainsi que de nombreux ONEtoONE relations, et la plupart des requêtes sur toute relation impliquant des jointures ou des comparaisons d'objets . Cela peut être un problème de performance majeur et vous devez toujours indexer vos champs de clés étrangères.
Pour a PRIMARY KEY
, un index sera créé avec le message suivant:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "index" for table "table"
Pour une FOREIGN KEY
, la contrainte ne sera pas créé s'il n'y a pas d' index sur la référe ed table.
Un index sur référe ING table n'est pas nécessaire (si désiré), et ne sera donc pas implicitement créé.