Qual è l'ordine dei record in una tabella con una chiave primaria composta

Question

In PostgreSQL, quando una combinazione di più colonne viene specificata come PRIMARY KEY, come vengono ordinati i record?

Ciò presuppone che PostgreSQL ordini i record nell'ordine della chiave primaria. Lo fa?

Inoltre, la chiave primaria è indicizzata automaticamente in caso di PostgreSQL?

Answer 1

Questa domanda fa presupporre erroneamente che la chiave primaria imponga un ordine di tabella. Non è così. Le tabelle PostgreSQL non hanno un ordine definito, con o senza una chiave primaria; sono un "mucchio" di righe disposte in blocchi di pagina. L'ordine viene imposto utilizzando la clausola ORDER BY quando richiesto.

Si potrebbe pensare che le tabelle PostgreSQL siano memorizzate come tabelle orientate agli indici che vengono memorizzate su disco in ordine di chiave primaria, ma non è così che funziona Pg. Penso che InnoDB memorizzi le tabelle organizzate dalla chiave primaria (ma non siano state controllate), ed è facoltativa in alcuni database di altri fornitori utilizzando una funzione spesso chiamata "indici cluster" o "tabelle organizzate per indice". Questa funzione non è attualmente supportata da PostgreSQL (come minimo da 9.3).

Detto questo, lo PRIMARY KEY viene implementato utilizzando un indice UNIQUE e vi è un ordinamento per tale indice. È ordinato in ordine crescente dalla colonna sinistra dell'indice (e quindi dalla chiave primaria) in poi, come se fosse ORDER BY col1 ASC, col2 ASC, col3 ASC;. Lo stesso vale per qualsiasi altro indice b-tree (come distinto da GiST o GIN) in PostgreSQL, dato che sono implementati usando b+trees.

Così nella tabella:

CREATE TABLE demo (
    a integer, 
    b text, 
    PRIMARY KEY(a,b) 
); 

il sistema creerà automaticamente l'equivalente di:

CREATE UNIQUE INDEX demo_pkey ON demo(a ASC, b ASC); 

Questo è riportato a voi quando si crea una tabella, ad esempio:

regress=>  CREATE TABLE demo (
regress(>  a integer, 
regress(>  b text, 
regress(>  PRIMARY KEY(a,b) 
regress(> ); 
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index "demo_pkey" for table "demo" 
CREATE TABLE 

È possibile visualizzare questo indice durante l'esame della tabella:

È possibile effettuare il CLUSTER in questo indice per riordinare la tabella in base alla chiave primaria, ma è un'operazione singola. Il sistema non manterrà questo ordine, anche se c'è spazio libero nelle pagine a causa di un valore non predefinito FILLFACTOR, penso che proverà a farlo.

Una conseguenza della ordinazione intrinseca dell'indice (ma non l'heap) è che è molto più veloce per cercare:

SELECT * FROM demo ORDER BY a, b; 
SELECT * FROM demo ORDER BY a; 

di:

SELECT * FROM demo ORDER BY a DESC, b; 

e nessuno dei due questi possono utilizzare l'indice della chiave primaria, eseguiranno un seqscan a meno che non si disponga di un indice su b:

SELECT * FROM demo ORDER BY b, a; 
SELECT * FROM demo ORDER BY b; 

Questo è perché PostgreSQL può utilizzare un indice su (a,b) quasi come un indice su (a) da solo.Non può usare un indice su (a,b) come se fosse un indice su (b) da solo - nemmeno lentamente, semplicemente non può.

Come per la voce DESC, per quel Pg deve eseguire una scansione dell'indice inverso, che è più lenta di una normale scansione indice in avanti. Se stai vedendo molte scansioni dell'indice inverso in EXPLAIN ANALYZE e puoi permetterti il ​​costo delle prestazioni dell'indice extra, puoi creare un indice sul campo nell'ordine DESC.

Questo vale per le clausole WHERE, non solo per ORDER BY. È possibile utilizzare un indice su (a,b) per cercare WHERE a = 4 o WHERE a = 4 AND b = 3 ma non per cercare solo WHERE b = 3.