Laut PostgreSQL Limits ist es "250 - 1600 je nach Spaltentyp". Siehe Hinweis unter der Tabelle. Die Spaltentypen wirken sich darauf aus, da Zeilen in PostgreSQL höchstens 8 KB (eine Seite) breit sein dürfen und sich nicht über Seiten erstrecken können. Große Werte in Spalten sind in Ordnung, weil TOAST damit umgeht, aber es gibt eine Grenze für die Anzahl der Spalten, die Sie einfügen können, die davon abhängt, wie breit die verwendeten nicht-TOAST-Datentypen sind.
(Streng genommen bezieht sich dies auf Spalten, die in Zeilen auf der Festplatte gespeichert werden können; Abfragen können möglicherweise breitere Spaltensätze als diese verwenden. Ich empfehle nicht, sich darauf zu verlassen.)
Wenn Sie auch nur daran denken, sich den Spaltengrenzen zu nähern, werden Sie wahrscheinlich Probleme haben.
Das Zuordnen von Tabellenkalkulationen zu relationalen Datenbanken scheint die einfachste Sache der Welt zu sein – ordnen Sie Spalten zu Spalten, Zeilen zu Zeilen zu und los geht’s. Recht? In Wirklichkeit sind Tabellenkalkulationen riesige Freiform-Monster, die keine Struktur erzwingen und wirklich unschön sein können. Relationale Datenbanken sind darauf ausgelegt, Lots zu verarbeiten mehr Zeilen, aber zu einem Preis; Im Fall von PostgreSQL besteht ein Teil dieser Kosten in einer Begrenzung, wie breit diese Zeilen sein sollen. Bei Tabellenkalkulationen, die von Joe User erstellt wurden, kann dies ein echtes Problem darstellen.
Eine "Lösung" besteht darin, sie in EAV zu zerlegen, aber das ist unsagbar langsam und hässlich, damit zu arbeiten. Bessere Lösungen verwenden wo möglich Arrays, zusammengesetzte Typen, hstore , json, xml usw.
Am Ende ist es jedoch manchmal die beste Lösung, die Tabelle mithilfe einer Tabelle zu analysieren.
