Det är faktiskt mer komplext än så.
Null-bitmappen behöver en bit per kolumn i raden, avrundad uppåt till hela byte. Den finns bara där om den faktiska raden innehåller minst ett NULL-värde och är fullt allokerad i så fall. NOT NULL begränsningar påverkar inte det direkt. (Naturligtvis, om alla fält i din tabell är NOT NULL , det kan aldrig finnas en noll bitmapp.)
"Heap tuple header" (per rad) är 23 byte lång. Faktisk data börjar med en multipel av MAXALIGN (Maximal datajustering ) efter det, vilket vanligtvis är 8 byte på 64-bitars OS (4 byte på 32-bitars OS). Kör följande kommando från din PostgreSQL binära dir som root för att få ett definitivt svar:
./pg_controldata /path/to/my/dbcluster
På en typisk Debian-baserad installation av Postgres 12 skulle det vara:
sudo /usr/lib/postgresql/12/bin/pg_controldata /var/lib/postgresql/12/main
Hur som helst, det finns en ledig byte mellan rubriken och den justerade starten av datan, som null-bitmappen kan använda. Så länge din tabell har 8 kolumner eller färre , NULL-lagring är faktiskt absolut gratis (när det gäller diskutrymme).
Efter det, ytterligare en MAXALIGN (vanligtvis 8 byte) tilldelas för noll-bitmappen för att täcka ytterligare (vanligtvis) 64 fält. Etc.
Detta är giltigt för åtminstone version 8.4 - 12 och kommer troligen inte att ändras.