PostgreSQL सीमा के अनुसार यह "250 - 1600 कॉलम प्रकारों के आधार पर" है। तालिका के नीचे नोट देखें। कॉलम प्रकार इसे प्रभावित करते हैं क्योंकि PostgreSQL में पंक्तियाँ अधिकतम 8kb (एक पृष्ठ) चौड़ी हो सकती हैं, वे पृष्ठों का विस्तार नहीं कर सकती हैं। कॉलम में बड़े मान ठीक हैं क्योंकि TOAST इसे संभालता है, लेकिन इसमें आप कितने कॉलम फिट कर सकते हैं इसकी एक सीमा है जो इस बात पर निर्भर करता है कि उपयोग किए गए अन-टोस्ट किए गए डेटा प्रकार कितने व्यापक हैं।
(सख्ती से यह उन स्तंभों को संदर्भित करता है जिन्हें ऑन-डिस्क पंक्तियों में संग्रहीत किया जा सकता है; प्रश्न इससे अधिक व्यापक कॉलम सेट का उपयोग करने में सक्षम हो सकते हैं। मैं इस पर भरोसा करने की अनुशंसा नहीं करता।)
यदि आप कॉलम की सीमा तक पहुंचने के बारे में भी सोच रहे हैं तो आपको शायद समस्याएँ होने वाली हैं।
स्प्रैडशीट्स को रिलेशनल डेटाबेस में मैप करना दुनिया की सबसे सरल चीज़ की तरह लगता है - कॉलम को कॉलम, रो से रो और गो को मैप करें। सही? हकीकत में, स्प्रैडशीट्स विशाल फ्रीफॉर्म राक्षस हैं जो बिना किसी संरचना को लागू करते हैं और वास्तव में बोझिल हो सकते हैं। संबंधपरक डेटाबेस बहुत से . को संभालने के लिए डिज़ाइन किए गए हैं अधिक पंक्तियाँ, लेकिन एक कीमत पर; PostgreSQL के मामले में उस लागत का हिस्सा एक सीमा है कि वह उन पंक्तियों को कितना व्यापक पसंद करता है। जो उपयोगकर्ता द्वारा बनाई गई स्प्रेडशीट का सामना करते समय यह एक वास्तविक समस्या हो सकती है।
एक "समाधान" उन्हें ईएवी में विघटित करना है, लेकिन यह काम करने के लिए बहुत धीमा और बदसूरत है। बेहतर समाधान जहां संभव हो वहां सरणियों का उपयोग कर रहे हैं, समग्र प्रकार, hstore , जेसन, एक्सएमएल, आदि।
अंत में, हालांकि, कभी-कभी सबसे अच्छा उत्तर स्प्रेडशीट का उपयोग करके स्प्रेडशीट का विश्लेषण करना होता है।
