Postgres e indici su chiavi esterne e chiavi primarie

Postgres inserisce automaticamente gli indici su chiavi esterne e chiavi primarie? Come posso dirlo? Esiste un comando che restituirà tutti gli indici su una tabella?

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

Quando Pg crea un indice implicito, emetterà un NOTICEmessaggio di livello che puoi vedere nei psqlregistri di sistema e / o, in modo da poter vedere quando succede. Gli indici creati automaticamente sono visibili anche \dnell'output di una tabella.

La documentazione sugli indici univoci dice:

PostgreSQL crea automaticamente un indice per ogni vincolo univoco e vincolo chiave primaria per imporre l'univocità. Pertanto, non è necessario creare un indice in modo esplicito per le colonne chiave primaria.

e la documentazione sui vincoli dice:

Poiché una ELIMINAZIONE di una riga dalla tabella referenziata o un AGGIORNAMENTO di una colonna referenziata richiederanno una scansione della tabella referenziante per le righe che corrispondono al vecchio valore, è spesso una buona idea indicizzare le colonne referenziate. Poiché ciò non è sempre necessario e sono disponibili molte opzioni 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.

Nota che se usi chiavi primarie, come 2 FK come PK in una tabella da M a N, avrai un indice sul PK e probabilmente non avrai bisogno di creare altri indici.

Sebbene di solito sia una buona idea creare un indice su (o includere) le colonne di chiavi esterne sul lato di riferimento, non è necessario. Ogni indice che aggiungi rallenta leggermente le operazioni DML, quindi paghi un costo di rendimento su ogni INSERT, UPDATEo DELETE. Se l'indice viene utilizzato raramente, potrebbe non valerne la pena.

Se desideri elencare gli indici di tutte le tabelle nei tuoi schemi dal tuo programma, tutte le informazioni sono disponibili 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 vuoi approfondire ulteriormente (come colonne e ordini), devi guardare pg_catalog.pg_index. L'uso psql -E [dbname]è utile per capire come interrogare il catalogo.

Questa query elencherà gli indici mancanti su chiavi esterne , sorgente originale .

Modifica : Nota che non controllerà le tabelle piccole (meno di 9 MB) e alcuni altri casi. Vedi la WHEREdichiarazione 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;

Sì - per le chiavi primarie, no - per le chiavi esterne (altro nei documenti ).

\d <table_name>

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

Adoro il modo in cui questo è spiegato nell'articolo Funzionalità interessanti di EclipseLink 2.5

Indicizzazione di chiavi esterne

La prima funzione è l'indicizzazione automatica delle chiavi esterne. Molte persone presumono erroneamente che i database indicizzino le chiavi esterne per impostazione predefinita. Beh, non lo fanno. Le chiavi primarie sono indicizzate automaticamente, ma non le chiavi esterne. Ciò significa che qualsiasi query basata sulla chiave esterna eseguirà scansioni di tabelle complete. Questa è una relazione OneToMany , ManyToMany o ElementCollection , nonché molte relazioni OneToOne e la maggior parte delle query su qualsiasi relazione che coinvolge join o confronti di oggetti . Questo può essere un grosso problema e dovresti sempre indicizzare i campi delle tue chiavi esterne.

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

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

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

Un indice su referenc ing tavolo non è necessaria (se desiderato), e pertanto non verrà creato implicitamente.