Postgres et index sur les clés étrangères et les clés primaires
Postgres met-il automatiquement des index sur les clés étrangères et les clés primaires? Comment puis-je savoir? Existe-t-il une commande qui renverra tous les index d'une table?
PostgreSQL crée automatiquement des index sur les clés primaires et des contraintes uniques, mais pas du côté des références des relations de clés étrangères.
Lorsque Pg crée un index implicite, il envoie un message de niveau NOTICE que vous pouvez voir dans psql et/ou dans les journaux système, afin que vous puissiez voir quand cela se produit. Les index créés automatiquement sont également visibles dans la sortie \d d'une table.
Le documentation sur les index uniques dit:
PostgreSQL crée automatiquement un index pour chaque contrainte unique et chaque contrainte de clé primaire afin de renforcer l'unicité. Ainsi, il n'est pas nécessaire de créer explicitement un index pour les colonnes de clé primaire.
et la documentation sur contraintes dit:
Etant donné qu'un DELETE d'une ligne de la table référencée ou une UPDATE d'une colonne référencée nécessitera une analyse de la table référençante pour les lignes correspondant à l'ancienne valeur, il est souvent conseillé d'indexer les colonnes référencées. Comme cela n'est pas toujours nécessaire et qu'il existe de nombreux choix en matière d'indexation, 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 si vous les voulez.
Notez que si vous utilisez des clés étrangères principales, telles que 2 FK en tant que PK dans une table M-à-N, vous aurez un index sur le PK et n'avez probablement pas besoin de créer d'index supplémentaire.
Bien qu'il soit généralement judicieux de créer un index sur (ou y compris) vos colonnes de clé étrangère côté référencement, cela n'est pas obligatoire. Chaque index que vous ajoutez ralentit légèrement les opérations DML, de sorte que vous payez un coût de performance sur chaque INSERT, UPDATE ou DELETE. Si l'index est rarement utilisé, cela ne vaut peut-être pas la peine.
Si vous souhaitez répertorier les index de toutes les tables de votre/vos schéma (s) de votre programme, toutes les informations sont disponibles 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 voulez aller plus loin (comme les colonnes et le classement), vous devez regarder pg_catalog.pg_index. Utiliser psql -E [dbname] est très utile pour savoir comment interroger le catalogue.
Cette requête listera les index manquants sur les clés étrangères , source originale .
-- 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;
J'adore la façon dont cela est expliqué dans l'article Fonctionnalités de performances d'EclipseLink 2.5 super cool
Indexation des clés étrangères
La première fonction 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, ils ne le font pas. Les clés primaires sont auto-indexées, mais pas les clés étrangères. Cela signifie que toute requête basée sur la clé étrangère effectuera des analyses de table complètes. C'est tout OneToMany , ManyToMany ou ElementCollection , ainsi que plusieurs 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 majeur et vous devez toujours indexer vos champs de clés étrangères.
Pour un PRIMARY KEY, un index sera créé avec le message suivant:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "index" for table "table"
Pour un FOREIGN KEY, la contrainte ne sera pas créée s'il n'y a pas d'index sur la table referenc ed.
Un index sur la table referenc ing n'est pas obligatoire (bien que souhaité) et ne sera donc pas créé implicitement.