¿Las columnas anulables ocupan espacio adicional en PostgreSQL?

Question

Tengo una tabla con 7 columnas y 5 de ellas serán nulas. Tendré columnas nulas en int, text, date, boolean y money tipos de datos. Esta tabla contendrá millones de filas con muchos nulos. Me temo que los valores nulos ocuparán espacio.

Además, ¿sabe si Postgres indexa valores nulos? Me gustaría evitar que indexe nulos.

Answer 1

Básicamente, los valores NULL ocupan 1 bit en el mapa de bits NULO. Pero no es tan simple como eso.

null mapa de bits (por fila) solo está allí si al menos una columna en esa fila tiene un valor de NULL. Esto puede llevar a un efecto paradox en tablas con 9 o más columnas: la asignación del primer valor NULL a una columna puede ocupar más espacio en el disco que escribirle un valor. Por el contrario, con la última columna que no sea nula, el mapa de bits nulo se descarta para la fila.

Físicamente, el mapa de bits inicial nula ocupa 1 byte entre las HeapTupleHeader (23 bytes) y los datos de las columnas reales o la fila OID (si todavía debe utilizar eso) - el cual siempre inicio a un múltiplo de MAXALIGN (típicamente 8 bytes). Esto deja 1 byte de relleno que es utilizado por el mapa de bits nulo inicial.

En efecto El almacenamiento NULL es totalmente gratuito para tablas de 8 columnas o menos.
Después de eso, se asignan otros MAXALIGN bytes (generalmente 8) para las siguientes columnas MAXALIGN * 8 (normalmente 64). Etc.

Más detalles in the manual y bajo estas preguntas relacionadas:

• How much disk-space is needed to store a NULL value using postgresql DB?
• Does not using NULL in PostgreSQL still use a NULL bitmap in the header?
• How many records can I store in 5 MB of PostgreSQL on Heroku?

Una vez que entienda el relleno alineación de los tipos de datos, se puede optimizar aún más el almacenamiento :

• Calculating and saving space in PostgreSQL

Pero los casos son raros donde se puede ahorrar cantidades considerables de espacio. Normalmente no vale la pena el esfuerzo.

@Daniel ya cubre los efectos en el tamaño del índice.

Answer 2

Creo que cada uno usaría un solo bit en el mapa de bits para la fila. Vea aquí: http://www.postgresql.org/docs/9.0/static/storage-page-layout.html#HEAPTUPLEHEADERDATA-TABLE

Answer 3

Si los valores NULL llegan al índice o no dependen al menos del tipo del índice. Básicamente, esto sería SÍ para btree y gist tipos de índices, NO para hash, y parece SÍ o NO para gin tipos de índices en función de la versión de PostgreSQL.

Solía ​​haber una columna booleana amindexnulls en la tabla pg_catalog.pg_am que contenía esa información, pero no está en 9.1. Probablemente porque los índices se han vuelto aún más sofisticados entre las mejoras PG.

En el caso específico de sus datos, la mejor manera de saber sería medir la diferencia de tamaño de los índices, utilizando la función pg_relation_size('index_name'), entre los contenidos completamente NULOS y completamente NO NULOS, con su versión PG exacta, tipo de datos exacto, tipo de índice exacto y definición. Y sepa que posiblemente, un cambio futuro en cualquiera de estos parámetros puede cambiar el resultado.

Pero en cualquier caso, si "sólo" quiere evitar los nulos de indexación, que siempre es posible crear un índice parcial:

CREATE INDEX partial_idx(col) ON table WHERE (col is not null) 

Esto va a tomar menos espacio, pero si esto se va a la ayuda o no con la realización de consultas depende de estas consultas.