FILLFACTOR
Med endast INSERT och SELECT du bör använda en FILLFACTOR av 100 överallt.
Det är ingen idé att lämna rörelseutrymme per minnesblock om du inte ska "vicka" med UPDATE s.
Mekanismen bakom FILLFACTOR är väldigt enkelt. INSERT s fyller bara varje datasida (vanligtvis ett 8 kb-block) upp till den procentandel som anges av FILLFACTOR miljö. Dessutom, när du kör VACUUM FULL eller CLUSTER på bordet återupprättas samma vickningsrum per block. Helst tillåter detta UPDATE s för att lagra nya radversioner på samma datasida, vilket kan ge en avsevärd prestandahöjning när man hanterar många UPDATE s. Även fördelaktigt i kombination med H.O.T. uppdateringar :
Om det finns ingen uppdateringar, slösa inte utrymme på detta och ställ in FILLFACTOR = 100 .
Grundläggande informationskälla:manualen om CREATE TABLE
eller CREATE INDEX .
Annan optimering
Men du kan göra något annat - eftersom du verkar vara en sugen på optimering ... :)
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));
Detta optimerar din tabell med avseende på datajustering och undviker stoppning för en typisk 64-bitars server och sparar några byte, förmodligen bara 8 byte i genomsnitt - du kan vanligtvis inte pressa ut mycket med "column tetris:
Behåll också NOT NULL kolumner i början av tabellen för en mycket liten prestationsbonus.
Din tabell har också 9 kolumner . Detta innebär ytterligare 8 byte för den utökade NULL-bitmappen - som skulle passa in i den initiala 1-byte NULL-bitmappen för bara 8 kolumner .
Om du definierar et_mode och token NOT NULL , alla kolumner är NOT NULL och NULL-bitmappen används överhuvudtaget, vilket frigör 8 byte.
Detta fungerar till och med per rad om du inte deklarerar kolumnerna NOT NULL . Om alla kolumner har värden finns det ingen NULL-bitmapp för den här raden. I ditt fall leder detta till den paradoxala effekten att fylla i värden för et_mode och token kan göra din lagringsstorlek mindre eller åtminstone förbli densamma:
Grundläggande informationskälla:handboken om fysisk databaslagring .
Jämför storleken på rader (fyllda med värden) med din ursprungliga tabell för att få definitiva bevis:
SELECT pg_column_size(t) FROM dev_transactions t;