Според ограниченията на PostgreSQL това е "250 - 1600 в зависимост от типовете колони". Вижте бележката под таблицата. Типовете колони го засягат, защото в PostgreSQL редовете може да са най-много 8kb (една страница) широки, те не могат да обхващат страници. Големите стойности в колоните са ОК, защото TOAST се справя с това, но има ограничение за броя на колоните, които можете да поберете, което зависи от това колко широки са използваните не-TOAST типове данни.
(Това се отнася строго за колони, които могат да се съхраняват в редове на диска; заявките може да могат да използват по-широки набори от колони от това. Не препоръчвам да разчитате на него.)
Ако дори мислите да се доближите до границите на колоните, вероятно ще имате проблеми.
Съпоставянето на електронни таблици в релационни бази данни изглежда като най-простото нещо на света – картографирайте колони към колони, редове към редове и тръгвайте. нали така? В действителност електронните таблици са огромни чудовища в свободна форма, които не налагат никаква структура и могат да бъдат наистина лоши. Релационните бази данни са проектирани да обработват партии повече редове, но на цена; в случая на PostgreSQL част от тази цена е ограничение за това колко широки желае да бъдат тези редове. Когато се сблъскате с електронни таблици, създадени от Joe User, това може да бъде истински проблем.
Едно „решение“ е да ги разложите в EAV, но това е неописуемо бавно и грозно за работа. По-добрите решения са използването на масиви, където е възможно, съставни типове, hstore , json, xml и др.
В крайна сметка обаче понякога най-добрият отговор е да анализирате електронната таблица с помощта на електронна таблица.
