Tableau K.1 décrit les diverses limites dures de PostgreSQL. Cependant, les limites physiques telles que les limitations de performance ou l'espace disque disponible peuvent s'appliquer avant que des limites dures absolues soient atteintes.
Tableau K.1. Limitations de PostgreSQL
| Élément | Limite supérieure | Commentaire |
|---|---|---|
| taille de la base de données | illimitée | |
| nombre de bases de données | 4 294 950 911 | |
| relations par base de données | 1 431 650 303 | |
| taille d'une relation | 32 To | Avec un BLCKSZ par défaut de 8192 octets |
| lignes par table | limité par le nombre de lignes qui peuvent être contenus dans 4 294 967 295 blocs | |
| colonnes par table | 1600 | aussi limité par la taille des lignes contenues dans un simple bloc ; voir la note ci dessous |
| colonnes par ensemble de résultat | 1664 | |
| colonnes par ensemble de résultats | 1664 | |
| taille d'un champs | 1 Go | |
| index par table | illimitée | limité par le nombre maximum de relations par base de données |
| colonnes par index | 32 | peut être augmenté en recompilant PostgreSQL |
| clés de partition | 32 | peut être augmenté en recompilant PostgreSQL |
| longueur de l'identifiant | 63 octets | peut être augmenté en recompilant PostgreSQL |
| arguments de fonction | 100 | peut être augmenté en recompilant PostgreSQL |
| paramètres de requête | 65 535 |
Le nombre maximum de colonnes pour une table est d'autant plus réduit que la
ligne stockée doit être contenu dans un simple bloc de 8192 octets.
Par exemple, sans compter l'entête d'une ligne, une ligne constituée de 1600 colonnes de type
int consommera 6400 octets et peut être stocké dans un bloc, mais une ligne
constituée de 1600 colonnes de type bigint consommera 12800 octets et
ne pourra pas tenir dans le bloc.
Les champs typés text, varchar et char de longueur variable
peuvent avoir leurs valeurs stockées à l'extérieur dans une table TOAST lorsque cette valeur
est suffisamment importante pour que cela se produise.
Un pointeur de 18 octets doit rester à l'intérieur de la ligne dans la table. Pour des longueurs
moins importantes de champs à longueur variable, un champ entête de 4-octets ou 1-octet est
utilisé et la valeur est stockée à l'intérieur de la ligne.
Les colonnes qui ont été supprimées de la table participent aussi à la limite maximum de colonnes. De plus, bien que les valeurs des colonnes supprimées pour les nouvelles lignes créées soient marquées en interne comme null, ainsi que dans le champ de bits des valeurs null de la ligne, ce champ consomme de l'espace.
Chaque table peut enregistrer un maximum théorique de 2^32 valeurs hors ligne ;; voir Section 65.2 pour une discussion détaillée sur le stockage hors ligne. Cette limite vient de l'utilisation d'un OID 32 bits pour identifier chacune de ces valeurs. La limite pratique est significativement inférieure à la limite théorique parce que comme l'espace d'OID se remplit, trouver un OID toujours libre devient coûteux, ce qui ralentit les instructions INSERT/UPDATE. C'est uniquement un problème pour les tables contenant plusieurs téra-octets de données ; le partitionnement est un contournement possible.
Chaque table peut enregistrer un maximum théorique de 2^32 valeurs hors ligne ; voir Section 65.2 pour une discussion détaillée du stockahe hors ligne. Cette limitevient de l'utilisation d'un OID sur 32 bits pour identifier chaque valeur. La limite pratique est significativement moindre que la limite théorique parce qu'au fur et à mesure que l'espace OID se remplit, trouver nu OID toujours libre devient coûteux, ralentissant de ce fait les instructions INSERT/UPDATE. Typiquement, c'est seulement un problème pour les tables contenant plusieurs téra-octets de données ; partitionner est un contournement possible.
