La Table K.1 describe varios límites estrictos de PostgreSQL. Sin embargo, los límites prácticos, tales como las limitaciones de rendimiento o el espacio en disco disponible, pueden aplicar antes de que se alcancen los límites estrictos absolutos.
Table K.1. Limitaciones de PostgreSQL
| Elemento | Límite superior | Comentario |
|---|---|---|
| tamaño de la base de datos | ilimitado | |
| número de bases de datos | 4,294,950,911 | |
| relaciones por base de datos | 1,431,650,303 | |
| tamaño de la relación | 32 TB | con el BLCKSZ por defecto de 8192 bytes |
| filas por tabla | limitado por el número de tuplas que caben en 4,294,967,295 páginas | |
| columnas por tabla | 1,600 | además limitado por el hecho de que el tamaño de la tupla debe caber en una sola página; ver la nota de abajo |
| columnas en un conjunto de resultados | 1,664 | |
| tamaño de campo | 1 GB | |
| índices por tabla | ilimitado | restringido por el máximo de relaciones por base de datos |
| columnas por índice | 32 | se puede aumentar recompilando PostgreSQL |
| claves de partición | 32 | se puede aumentar recompilando PostgreSQL |
| longitud del identificador | 63 bytes | se puede aumentar recompilando PostgreSQL |
| argumentos de función | 100 | se puede aumentar recompilando PostgreSQL |
| parámetros de consulta | 65,535 |
El número máximo de columnas para una tabla se reduce aún más dado que la
tupla que se almacena debe caber en una sola página de almacenamiento (heap page)
de 8192 bytes. Por ejemplo, excluyendo la cabecera de la tupla, una tupla compuesta
por 1,600 columnas de tipo int consumiría 6400 bytes y podría almacenarse
en una página de almacenamiento, pero una tupla de 1,600 columnas de tipo
bigint consumiría 12800 bytes y, por lo tanto, no cabría dentro de
una página de almacenamiento. Los campos de longitud variable de tipos como
text, varchar y char pueden tener sus
valores almacenados fuera de línea en la tabla TOAST de la tabla cuando los valores
son lo suficientemente grandes como para requerirlo. Solo un puntero de 18 bytes
debe permanecer dentro de la tupla en la página de almacenamiento de la tabla.
Para campos de longitud variable más cortos, se utiliza una cabecera de campo de
4 bytes o 1 byte y el valor se almacena dentro de la tupla de la página de almacenamiento.
Las columnas que han sido eliminadas de la tabla también contribuyen al límite máximo de columnas. Además, aunque los valores de las columnas eliminadas para las tuplas recién creadas se marcan internamente como nulos en el mapa de bits de nulos de la tupla, este mapa de bits también ocupa espacio.
Cada tabla puede almacenar un máximo teórico de 2^32 valores fuera de línea; ver la Section 66.2 para una discusión detallada del almacenamiento fuera de línea. Este límite surge del uso de un OID de 32 bits para identificar cada uno de esos valores. El límite práctico es significativamente menor que el límite teórico, porque a medida que el espacio de OIDs se llena, encontrar un OID que aún esté libre puede volverse costoso, lo que a su vez ralentiza las sentencias INSERT/UPDATE. Típicamente, esto solo es un problema para tablas que contienen muchos terabytes de datos; la partición es una posible solución.