FILLFACTOR
Kun med INSERT og SELECT du skal bruge en FILLFACTOR af 100 overalt.
Det nytter ikke at forlade slingreplads pr. hukommelsesblok, hvis du ikke skal "vrikke" med UPDATE s.
Mekanismen bag FILLFACTOR er meget enkel. INSERT s udfylder kun hver dataside (normalt en 8 kb blokke) op til den procentdel, der er angivet af FILLFACTOR indstilling. Også når du kører VACUUM FULL eller CLUSTER på bordet genetableres det samme vrikkerum pr. blok. Ideelt set tillader dette UPDATE s for at gemme nye rækkeversioner på den samme dataside, hvilket kan give et væsentligt ydelsesboost, når man håndterer mange UPDATE s. Også gavnlig i kombination med H.O.T. opdateringer :
Hvis der er ingen opdateringer, spild ikke plads på dette og indstil FILLFACTOR = 100 .
Grundlæggende informationskilde:manualen om CREATE TABLE
eller CREATE INDEX .
Anden optimering
Men du kan gøre noget andet - da du tilsyneladende er en sucker for 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));
Dette optimerer din tabel med hensyn til datajustering og undgår polstring for en typisk 64 bit server og sparer et par bytes, sandsynligvis kun 8 byte i gennemsnit - du kan typisk ikke presse meget ud med "column tetris:
Behold også NOT NULL kolonner i starten af bordet for en meget lille præstationsbonus.
Din tabel har også 9 kolonner . Dette betyder en ekstra 8 bytes for den udvidede NULL bitmap - som ville passe ind i den indledende 1-byte NULL bitmap for kun 8 kolonner .
Hvis du definerer et_mode og token NOT NULL , alle kolonner er NOT NULL og NULL bitmap bruges overhovedet, hvilket frigør 8 bytes.
Dette virker endda pr. række, hvis du ikke erklærer kolonnerne NOT NULL . Hvis alle kolonner har værdier, er der ingen NULL bitmap for denne række. I dit tilfælde fører dette til den paradoksale effekt, at udfyldning af værdier for et_mode og token kan gøre din lagerstørrelse mindre eller i det mindste forblive den samme:
Grundlæggende informationskilde:manualen om databasefysisk lagring .
Sammenlign størrelsen af rækker (fyldt med værdier) med din oprindelige tabel for at få et endeligt bevis:
SELECT pg_column_size(t) FROM dev_transactions t;