Volgens PostgreSQL-limieten is het "250 - 1600, afhankelijk van kolomtypes". Zie opmerking onder de tabel. De kolomtypen beïnvloeden dit omdat in PostgreSQL-rijen maximaal 8 kb (één pagina) breed mogen zijn, ze geen pagina's kunnen overspannen. Grote waarden in kolommen zijn OK omdat TOAST daarmee omgaat, maar er is een limiet aan het aantal kolommen dat u kunt plaatsen, afhankelijk van hoe breed de niet-TOAST-gegevenstypen zijn die worden gebruikt.
(Dit verwijst strikt naar kolommen die kunnen worden opgeslagen in rijen op schijf; query's kunnen mogelijk bredere kolommensets gebruiken. Ik raad niet aan om erop te vertrouwen.)
Als u er zelfs maar aan denkt om de kolomlimieten te benaderen, krijgt u waarschijnlijk problemen.
Het in kaart brengen van spreadsheets aan relationele databases lijkt de eenvoudigste zaak van de wereld:kolommen toewijzen aan kolommen, rijen aan rijen en ga zo maar door. Rechts? In werkelijkheid zijn spreadsheets enorme monsters in vrije vorm die geen structuur afdwingen en erg onhandig kunnen zijn. Relationele databases zijn ontworpen om loten te verwerken meer rijen, maar tegen een prijs; in het geval van PostgreSQL is een deel van die kosten een beperking van hoe breed het die rijen wil hebben. Bij spreadsheets die door Joe User zijn gemaakt, kan dit een echt probleem zijn.
Een "oplossing" is om ze te ontleden in EAV, maar dat is onuitsprekelijk traag en lelijk om mee te werken. Betere oplossingen zijn het gebruik van arrays waar mogelijk, samengestelde typen, hstore , json, xml, enz.
Maar uiteindelijk is soms het beste antwoord om de spreadsheet te analyseren met behulp van een spreadsheet.