FILLFACTOR
Met alleen INSERT en SELECT gebruik een FILLFACTOR van 100 overal.
Het heeft geen zin om per geheugenblok bewegingsruimte te laten als je niet gaat "wiebelen" met UPDATE v.
Het mechanisme achter FILLFACTOR is heel eenvoudig. INSERT s vul alleen elke gegevenspagina (meestal een blok van 8 kb) tot het percentage dat is aangegeven door de FILLFACTOR instelling. Ook wanneer u VACUUM FULL . uitvoert of CLUSTER op tafel wordt dezelfde bewegingsruimte per blok hersteld. Idealiter staat dit UPDATE . toe s om nieuwe rijversies op dezelfde gegevenspagina op te slaan, wat een aanzienlijke prestatieverbetering kan opleveren bij veel UPDATE s. Ook gunstig in combinatie met H.O.T. updates :
Als er geen . zijn updates, verspil hier geen ruimte voor en stel FILLFACTOR = 100 in .
Basisinformatiebron:de handleiding op CREATE TABLE
of CREATE INDEX .
Andere optimalisatie
Maar je kunt iets anders doen - aangezien je een sukkel lijkt te zijn voor optimalisatie ... :)
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));
Dit optimaliseert uw tabel met betrekking tot gegevensuitlijning en vermijdt opvulling voor een typische 64-bits server en bespaart een paar bytes, waarschijnlijk gemiddeld slechts 8 bytes - je kunt er meestal niet veel uit persen met "column tetris:
Bewaar ook NOT NULL kolommen aan het begin van de tabel voor een zeer kleine prestatiebonus.
Uw tabel heeft ook 9 kolommen . Dit betekent een extra 8 bytes voor de uitgebreide NULL bitmap - die zou passen in de initiële 1-byte NULL-bitmap voor slechts 8 kolommen .
Als u et_mode definieert en token NOT NULL , alle kolommen zijn NOT NULL en de NULL-bitmap wordt helemaal niet gebruikt, waardoor 8 bytes vrijkomen.
Dit werkt zelfs per rij als u de kolommen niet declareert NOT NULL . Als alle kolommen waarden hebben, is er geen NULL-bitmap voor deze rij. In jouw geval leidt dit tot het paradoxale effect dat het invullen van waarden voor et_mode en token kan uw opslagruimte kleiner maken of in ieder geval hetzelfde blijven:
Basisinformatiebron:de handleiding over fysieke databaseopslag .
Vergelijk de grootte van rijen (gevuld met waarden) met uw originele tabel om definitief bewijs te krijgen:
SELECT pg_column_size(t) FROM dev_transactions t;