Według PostgreSQL Limits jest to "250 - 1600 w zależności od typu kolumny". Patrz uwaga pod tabelą. Typy kolumn mają na to wpływ, ponieważ wiersze PostgreSQL mogą mieć szerokość co najwyżej 8kb (jedna strona), nie mogą obejmować stron. Duże wartości w kolumnach są w porządku, ponieważ obsługuje to TOAST, ale istnieje limit liczby kolumn, które można zmieścić, zależy to od tego, jak szerokie są używane typy danych nie-TOAST.
(Dokładnie odnosi się to do kolumn, które mogą być przechowywane w wierszach na dysku; zapytania mogą używać szerszych zestawów kolumn niż ten. Nie polecam na tym polegać.)
Jeśli nawet myślisz o zbliżeniu się do limitów kolumn, prawdopodobnie będziesz mieć problemy.
Mapowanie arkuszy kalkulacyjnych do relacyjnych baz danych wydaje się najprostszą rzeczą na świecie — mapowanie kolumn na kolumny, wierszy na wiersze i przejście. Dobrze? W rzeczywistości arkusze kalkulacyjne to ogromne potwory o dowolnych kształtach, które nie wymuszają żadnej struktury i mogą być naprawdę nieporadne. Relacyjne bazy danych są zaprojektowane do obsługi dużych więcej rzędów, ale kosztem; w przypadku PostgreSQL część tego kosztu jest ograniczeniem szerokości tych wierszy. W obliczu arkuszy kalkulacyjnych stworzonych przez Joe Usera może to stanowić prawdziwy problem.
Jednym "rozwiązaniem" jest rozłożenie ich na EAV, ale jest to niewypowiedzianie powolne i brzydkie w pracy. Lepsze rozwiązania wykorzystują tablice tam, gdzie to możliwe, typy złożone, hstore , json, xml itp.
Ostatecznie jednak czasami najlepszą odpowiedzią jest przeanalizowanie arkusza kalkulacyjnego za pomocą arkusza kalkulacyjnego.
