Selon les limites de PostgreSQL, c'est "250 - 1600 selon les types de colonnes". Voir note sous le tableau. Les types de colonnes l'affectent car dans PostgreSQL, les lignes peuvent avoir une largeur maximale de 8 Ko (une page), elles ne peuvent pas s'étendre sur plusieurs pages. Les grandes valeurs dans les colonnes sont acceptables car TOAST gère cela, mais il y a une limite au nombre de colonnes que vous pouvez intégrer qui dépend de la largeur des types de données non TOAST utilisés.
(Cela fait strictement référence aux colonnes qui peuvent être stockées dans des lignes sur disque ; les requêtes peuvent être en mesure d'utiliser des ensembles de colonnes plus larges que cela. Je ne recommande pas de s'y fier.)
Si vous envisagez même d'approcher les limites de colonne, vous allez probablement avoir des problèmes.
Mapper des feuilles de calcul sur des bases de données relationnelles semble être la chose la plus simple au monde - mapper des colonnes sur des colonnes, des lignes sur des lignes, et c'est parti. À droite? En réalité, les feuilles de calcul sont d'énormes monstres de forme libre qui n'imposent aucune structure et peuvent être vraiment compliqués. Les bases de données relationnelles sont conçues pour gérer des lots plus de rangées, mais à un coût ; dans le cas de PostgreSQL, une partie de ce coût est une limitation de la largeur souhaitée pour ces lignes. Lorsque vous faites face à des feuilles de calcul créées par Joe User, cela peut être un réel problème.
Une "solution" consiste à les décomposer en EAV, mais c'est incroyablement lent et laid à travailler. Les meilleures solutions utilisent des tableaux dans la mesure du possible, des types composites, hstore , json, xml, etc.
En fin de compte, cependant, la meilleure réponse consiste parfois à analyser la feuille de calcul à l'aide d'une feuille de calcul.
