Facteur de remplissage pour un index séquentiel qui est PK

FILLFACTOR

Avec seulement INSERT et SELECT vous devez utiliser un FILLFACTOR de 100 partout.

Il ne sert à rien de laisser de la marge de manœuvre par bloc de mémoire si vous n'allez pas "bouger" avec UPDATE s.

Le mécanisme derrière FILLFACTOR est très simple. INSERT s remplir chaque page de données (généralement un bloc de 8 ko) jusqu'au pourcentage déclaré par le FILLFACTOR paramètre. De plus, chaque fois que vous exécutez VACUUM FULL ou CLUSTER sur la table, la même marge de manœuvre par bloc est rétablie. Idéalement, cela permet UPDATE s pour stocker de nouvelles versions de ligne dans la même page de données, ce qui peut fournir une amélioration substantielle des performances lorsqu'il s'agit de beaucoup de UPDATE s. Également bénéfique en combinaison avec H.O.T. mises à jour :

• Données redondantes dans les instructions de mise à jour

S'il n'y a non mises à jour, ne gaspillez pas d'espace pour cela et définissez FILLFACTOR = 100 .

Source d'information de base :le manuel sur CREATE TABLE ou CREATE INDEX .

Autre optimisation

Mais vous pouvez faire autre chose - puisque vous semblez être une ventouse pour l'optimisation... :)

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));

Cela optimise votre tableau en ce qui concerne l'alignement des données et évite le remplissage pour un serveur 64 bits typique et économise quelques octets, probablement seulement 8 octets en moyenne - vous ne pouvez généralement pas en extraire beaucoup avec "column tetris :

• Calculer et économiser de l'espace dans PostgreSQL

Aussi, gardez NOT NULL colonnes au début du tableau pour un très petit bonus de performance.

De plus, votre tableau comporte 9 colonnes . Cela signifie 8 octets supplémentaires pour le bitmap NULL étendu - qui tiendrait dans le bitmap NULL initial de 1 octet pour seulement 8 colonnes .
Si vous définissez et_mode et token NOT NULL , toutes les colonnes sont NOT NULL et le bitmap NULL est utilisé du tout, libérant 8 octets.
Cela fonctionne même par ligne si vous ne déclarez pas les colonnes NOT NULL . Si toutes les colonnes ont des valeurs, il n'y a pas de bitmap NULL pour cette ligne. Dans votre cas, cela conduit à l'effet paradoxal que de remplir des valeurs pour et_mode et token peut rendre votre taille de stockage plus petite ou au moins rester le même :

• Do nullable les colonnes occupent de l'espace supplémentaire dans PostgreSQL ?

Source d'information de base :le manuel sur le stockage physique de la base de données .

Comparez la taille des lignes (remplies de valeurs) avec votre tableau d'origine pour obtenir une preuve définitive :

SELECT pg_column_size(t) FROM dev_transactions t;