FILLFACTOR
Con solo INSERT e SELECT dovresti usare un FILLFACTOR di 100 ovunque.
Non ha senso lasciare spazio di manovra per blocco di memoria se non hai intenzione di "dimenare" con UPDATE s.
Il meccanismo alla base di FILLFACTOR è molto semplice. INSERT s riempire ogni pagina di dati (solitamente a blocchi di 8 kb) solo fino alla percentuale dichiarata dal FILLFACTOR ambientazione. Inoltre, ogni volta che esegui VACUUM FULL o CLUSTER sul tavolo si ristabilisce lo stesso spazio di manovra per blocco. Idealmente, questo consente UPDATE s per archiviare nuove versioni di riga nella stessa pagina di dati, che può fornire un notevole aumento delle prestazioni quando si ha a che fare con molti UPDATE S. Utile anche in combinazione con H.O.T. aggiornamenti :
Se ci sono nessun aggiornamenti, non sprecare spazio per questo e imposta FILLFACTOR = 100 .
Fonte di informazioni di base:il manuale su CREATE TABLE
o CREATE INDEX .
Altre ottimizzazioni
Ma puoi fare qualcos'altro - dal momento che sembri un fanatico dell'ottimizzazione ... :)
CREATE TABLE dev_transactions
( transaction_id serial PRIMARY KEY,
gateway integer NOT NULL,
moment timestamp NOT NULL,
transaction_type smallint NOT NULL,
status smallint NOT NULL,
device integer NOT NULL,
controler smallint NOT NULL,
token integer,
et_mode character(1));
Questo ottimizza la tua tabella per quanto riguarda l'allineamento dei dati ed evita il padding per un tipico server a 64 bit e consente di risparmiare pochi byte, probabilmente solo 8 byte in media - in genere non puoi spremere molto con "colonna tetris:
Inoltre, mantieni NOT NULL colonne all'inizio della tabella per un bonus di rendimento molto piccolo.
Inoltre, la tua tabella ha 9 colonne . Ciò significa un extra di 8 byte per la bitmap NULL estesa - che rientrerebbe nella bitmap NULL iniziale a 1 byte per solo 8 colonne .
Se definisci et_mode e token NOT NULL , tutte le colonne sono NOT NULL e viene utilizzata la bitmap NULL, liberando 8 byte.
Questo funziona anche per riga se non dichiari le colonne NOT NULL . Se tutte le colonne hanno valori, non esiste una bitmap NULL per questa riga. Nel tuo caso, questo porta all'effetto paradosso di riempire i valori per et_mode e token può ridurre le dimensioni dello spazio di archiviazione minore o almeno rimanere lo stesso:
Fonte di informazioni di base:il manuale sull'archiviazione fisica del database .
Confronta la dimensione delle righe (riempite di valori) con la tua tabella originale per ottenere una prova definitiva:
SELECT pg_column_size(t) FROM dev_transactions t;
