C'est en fait plus complexe que cela.
Le bitmap nul a besoin d'un bit par colonne dans la ligne, arrondi aux octets entiers. Il n'est là que si la ligne réelle comprend au moins une valeur NULL et est entièrement allouée dans ce cas. NOT NULL les contraintes n'affectent pas directement cela. (Bien sûr, si tous les champs de votre table sont NOT NULL , il ne peut jamais y avoir de bitmap nul.)
L'"en-tête de tuple de tas" (par ligne) a une longueur de 23 octets. Les données réelles commencent à un multiple de MAXALIGN (Alignement maximal des données ) après cela, qui est généralement de 8 octets sur un système d'exploitation 64 bits (4 octets sur un système d'exploitation 32 bits). Exécutez la commande suivante depuis votre répertoire binaire PostgreSQL en tant que root pour obtenir une réponse définitive :
./pg_controldata /path/to/my/dbcluster
Sur une installation typique basée sur Debian de Postgres 12, ce serait :
sudo /usr/lib/postgresql/12/bin/pg_controldata /var/lib/postgresql/12/main
Dans tous les cas, il y a un octet libre entre l'en-tête et le début aligné des données, que le bitmap nul peut utiliser. Tant que votre tableau comporte 8 colonnes ou moins , le stockage NULL est effectivement absolument gratuit (en ce qui concerne l'espace disque).
Après cela, un autre MAXALIGN (généralement 8 octets) est alloué au bitmap nul pour couvrir (généralement) 64 autres champs. Etc.
Ceci est valable au moins pour les versions 8.4 à 12 et ne changera probablement pas.
