A Tabela K.1 descreve vários limites rígidos do PostgreSQL. Entretanto, limites práticos, como limitações de desempenho, ou espaço em disco disponível, podem ocorrer antes que os limites rígidos absolutos sejam atingidos.
Tabela K.1. Limitações do PostgreSQL
Item | Limite superior | Comentário |
---|---|---|
tamanho do banco de dados | sem limite | |
número de bancos de dados | 4,294,950,911 | |
relações por banco de dados | 1,431,650,303 | |
tamanho da relação | 32 TB | com o BLCKSZ padrão de 8192 bytes |
linhas por tabela | limitado pelo número de tuplas que podem caber em 4.294.967.295 páginas | |
colunas por tabela | 1600 | limitado ainda mais pelo ajuste do tamanho da tupla em uma única página; veja nota abaixo |
colunas em um conjunto de resultados | 1664 | |
tamanho do campo | 1 GB | |
comprimento do identificador | 63 bytes | pode ser aumentado recompilando o PostgreSQL |
índices por tabela | sem limite | limitado pelo número máximo de relações por banco de dados |
colunas por índice | 32 | pode ser aumentado recompilando o PostgreSQL |
chaves de partição | 32 | pode ser aumentado recompilando o PostgreSQL |
O número máximo de colunas para uma tabela é ainda mais reduzido,
porque a tupla que está sendo armazenada deve caber em uma única
página de heap de 8192 bytes.
Por exemplo, excluindo o cabeçalho da tupla, uma tupla composta de 1600
colunas to tipo int
consumiria 6400 bytes, e poderia ser
armazenada em uma página do heap,
mas uma tupla de 1600 colunas do tipo bigint
consumiria
12800 bytes, portanto, não caberia em uma página de
heap.
Campos de comprimento variável de tipos como text
,
varchar
e char
podem ter seus valores
armazenados fora de linha na tabela TOAST
da tabela, quando os valores são grandes o suficiente para exigi-lo.
Somente um ponteiro de 18 bytes permanece dentro da tupla no
heap da tabela.
Para campos de comprimento variável de comprimento menor, um cabeçalho
de campo de 4 bytes ou 1 byte é usado. e o valor é armazenado dentro
da tupla no heap.
As colunas excluídas da tabela também contribuem para o limite máximo de colunas. Além disso, embora os valores das colunas excluídas para as linhas recém-criadas sejam marcados internamente como nulos, assim como no campo de bits de valores nulos da linha, esse campo consome espaço.