Postgres e indici su chiavi esterne e chiavi primarie

Question

Does Postgres inserisce automaticamente indici su chiavi esterne e chiavi primarie? Come posso dire? Esiste un comando che restituirà tutti gli indici su un tavolo?

Answer 1

PostgreSQL crea automaticamente indici su chiavi primarie e vincoli univoci, ma non sul lato di riferimento delle relazioni con le chiavi esterne.

Quando Pg crea un indice implicito emetterà un messaggio di livello NOTICE che è possibile vedere in psql e/oi registri di sistema, in modo da poter vedere quando succede. Gli indici creati automaticamente sono visibili anche nell'output \d per una tabella.

Il documentation on unique indexes dice:

PostgreSQL crea automaticamente un indice per ogni vincolo univoco e vincolo di chiave primaria per far rispettare l'unicità. Pertanto, non è necessario creare un indice esplicitamente per le colonne di chiavi primarie.

e la documentazione sul constraints dice:

Da un DELETE di una riga dalla tabella di riferimento o un aggiornamento di una colonna di riferimento richiederà una scansione di tabella di riferimento per righe corrispondenti al vecchio valore, è spesso una buona idea indicizzare le colonne di riferimento . Poiché questo non è sempre necessario, e ci sono molte scelte disponibili su come indicizzare, la dichiarazione di un vincolo di chiave esterna non crea automaticamente un indice sulle colonne di riferimento.

Pertanto è necessario creare indici su chiavi esterne se si desidera.

Si noti che se si utilizzano chiavi esterne principali, ad esempio 2 FK come PK in una tabella M-to-N, si avrà un indice sul PK e probabilmente non è necessario creare alcun indice aggiuntivo.

Mentre di solito è una buona idea creare un indice su (o includere) le colonne di chiavi esterne del lato di riferimento, non è necessario. Ogni indice aggiunto rallenta leggermente le operazioni DML, quindi si paga un costo di prestazioni su ogni INSERT, UPDATE o DELETE. Se l'indice viene usato raramente, potrebbe non valerne la pena.

Answer 2

Sì - per le chiavi primarie, no - per le chiavi esterne (altro nel docs).

\d <table_name> 

in "psql" mostra una descrizione di una tabella che include tutti gli indici.

Answer 3

Per un PRIMARY KEY, un indice verrà creato con il seguente messaggio:

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

Per un FOREIGN KEY, il vincolo non verrà creato se non v'è alcun indice sulla referenc ndr tavolo.

Un indice sulla tabella di riferimento it non è richiesto (sebbene desiderato) e pertanto non verrà creato in modo implicito.

Answer 4

Se si desidera elencare gli indici di tutte le tabelle nello schema (s) dal programma, tutte le informazioni sono a portata di mano nel catalogo:

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 

Se si vuole approfondire (ad esempio come colonne e ordinamento), devi dare un'occhiata a pg_catalog.pg_index. L'utilizzo di psql -E [dbname] è utile per capire come interrogare il catalogo.

Answer 5

Questa query lista mancanti indici sulle chiavi esterne, original source.

-- 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; 

Answer 6

Mi piace come questo è spiegato in questo articolo Cool performance features of EclipseLink 2.5

indicizzazione chiavi esterne

La prima caratteristica è automatica indicizzazione delle chiavi esterne. La maggior parte delle persone assume erroneamente che i database indice chiavi esterne per impostazione predefinita. Bene, non lo fanno. Le chiavi primarie sono auto indicizzate , ma le chiavi esterne non lo sono. Ciò significa che qualsiasi query basata sulla chiave esterna eseguirà scansioni complete della tabella. Questo è un qualsiasi OneToMany, ManyToMany o ElementCollection rapporto, così come molti OnetoOne relazioni, e maggior parte delle query su ogni rapporto che coinvolgono join o confronti degli oggetti. Questo può essere un importante problema, e dovresti indicizzare sempre i tuoi campi di chiavi esterne.