Postgresql

Question

में अधिकतम कॉलम की गणना कैसे करें मैं पोस्टग्रेस्क्ल तालिका में कॉलम की अधिकतम संख्या की गणना करने का सही तरीका क्या जानना चाहता हूं। यह अपनी वेबसाइट पर कहते हैं:

Maximum Columns per Table 250 - 1600 depending on column types

तो, स्तंभ प्रकार पर निर्भर करता है कि कैसे मैं अधिकतम कॉलम तय करते हैं?

Answer 1

आपको PostgreSQL के भौतिक डेटा संग्रहण के विवरण, अर्थात् Page Layout के विवरणों को देखने की आवश्यकता है।

1. जैसा कि आप जानते हैं, डिफ़ॉल्ट PostgreSQL ब्लॉक आकार 8kB (8192 बाइट्स) है। आपको यह भी पता होना चाहिए कि PostgreSQL तालिका पंक्तियों में ब्लॉक सीमा नहीं फैल सकती है। यह आपको पहले से ही 8192 बाइट्स की आकार सीमा देता है। लेकिन ...

2. उपरोक्त पृष्ठ लेआउट को देखते हुए PageHeader के लिए ओवरहेड भी है, जो वर्तमान PostgreSQL संस्करण पर 24 बाइट्स है। तो, हम 8168 बाइट्स के साथ छोड़ दिया गया है। लेकिन ...

3. ItemIdData भी है, जो पॉइंटर्स की सरणी है। आइए मान लें कि हमारे पास इस पृष्ठ पर केवल 1 रिकॉर्ड है, इसलिए इस प्रविष्टि में केवल 4 बाइट्स (1 एंट्री) है। तो, हम 8164 बाइट्स के साथ छोड़ दिया गया है। लेकिन ...

4. प्रत्येक रिकॉर्ड में RecordHeader भी है, जिसे 23 बाइट्स पर कब्जा करने के लिए जाना जाता है। तो, हम 8141 बाइट्स के साथ छोड़ दिया गया है। लेकिन ...

5. वहाँ भी RecordHeader के बाद एक NULL -bitmap सही है, लेकिन मान लें हम NOT NULL बाधा के साथ हमारे सभी स्तंभों द्वारा निर्धारित किए गए हैं। तो, यहां 8141 बाइट्स। लेकिन ...

6. ऐसी कोई बात है - MAXALIGN। एक नज़र डालें at this wonderful answer by Erwin। हम यहां 24+4+23=51 ऑफसेट के बारे में बात कर रहे हैं। अब सब कुछ आपके सिस्टम पर इस पैरामीटर के मान पर निर्भर करेगा।

   यदि यह 32-बिट एक है, तो ऑफ़सेट 52 पर गठबंधन किया जाएगा, जिसका अर्थ है कि हम एक और बाइट बर्बाद कर रहे हैं।

   यदि यह 64-बिट एक है, तो ऑफसेट 54 पर गठबंधन किया जाएगा, जिसका अर्थ है कि हम 3 और बाइट्स बर्बाद कर रहे हैं। मेरा सिस्टम 64-बिट एक है, इसलिए मुझे लगता है कि हम 8138 बाइट्स के साथ छोड़ दिए गए हैं।

तो यह वह स्थान है जहां हम छोड़े गए हैं। और अब सबकुछ हमारे द्वारा चुने गए कॉलम के प्रकारों पर निर्भर करेगा और वे एक साथ कैसे बैठेंगे (याद रखें कि MAXALIGN चीज़)। आइए सभी कॉलम के लिए int2 लें। सरल गणना से पता चलता है कि हम इस प्रकार के 4069 कॉलम में निचोड़ने में सक्षम होना चाहिए: सभी कॉलम NOT NULL और उसी प्रकार के।

सरल स्क्रिप्ट:

echo "CREATE TABLE tab4069 (" > tab4069.sql 
for num in $(seq -f "%04g" 1 4069); do 
    echo " col$num int2 not null," >> tab4069.sql; done 
echo " PRIMARY KEY (col0001));" >> tab4069.sql 

फिर भी, अगर आप इस तालिका बनाने के लिए कोशिश करता हूँ, तो आपको त्रुटि हिट होगी:

ERROR: tables can have at most 1600 columns

खोज बिंदु के थोड़ा the similar question करने के लिए और, के लिए देख the sources of the PostgreSQL में, हम इस सवाल का जवाब (लाइनों 23 से 47) मिलती है:

/* 
* MaxTupleAttributeNumber limits the number of (user) columns in a tuple. 
* The key limit on this value is that the size of the fixed overhead for 
* a tuple, plus the size of the null-values bitmap (at 1 bit per column), 
* plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most 
* machines the upper limit without making t_hoff wider would be a little 
* over 1700. We use round numbers here and for MaxHeapAttributeNumber 
* so that alterations in HeapTupleHeaderData layout won't change the 
* supported max number of columns. 
*/ 
#define MaxTupleAttributeNumber 1664  /* 8 * 208 */ 

/* 
* MaxHeapAttributeNumber limits the number of (user) columns in a table. 
* This should be somewhat less than MaxTupleAttributeNumber. It must be 
* at least one less, else we will fail to do UPDATEs on a maximal-width 
* table (because UPDATE has to form working tuples that include CTID). 
* In practice we want some additional daylight so that we can gracefully 
* support operations that add hidden "resjunk" columns, for example 
* SELECT * FROM wide_table ORDER BY foo, bar, baz. 
* In any case, depending on column data types you will likely be running 
* into the disk-block-based limit on overall tuple size if you have more 
* than a thousand or so columns. TOAST won't help. 
*/ 
#define MaxHeapAttributeNumber 1600  /* 8 * 200 */ 

बहुत सारे चर-लंबाई वाले प्रकार हैं, और वे वास्तविक मूल्य में 1 या 4 बाइट्स + कुछ बाइट्स के एक निश्चित ओवरहेड करते हैं। इसका मतलब है कि आप पहले से कभी नहीं जानते होंगे कि आपके पास वास्तविक मूल्य होने तक रिकॉर्ड कितना स्थान लेगा। बेशक, इन मानों को the TOAST के माध्यम से अलग से संग्रहीत किया जा सकता है, लेकिन आम तौर पर एक बड़ा (कुल लंबाई का 2kB गोल)।

कृपया, लंबाई लंबाई प्रकारों के लिए उपयोग की जाने वाली जगह का पता लगाने के लिए official docs on types से परामर्श लें। आप किसी भी प्रकार के लिए pg_column_size() फ़ंक्शन का आउटपुट भी देख सकते हैं, खासकर जटिल लोगों के लिए, जैसे कि एरे, hstore या jsonb।

यदि आप इस विषय पर अधिक पूर्ण दृष्टि चाहते हैं तो आपको अधिक जानकारी प्राप्त करनी होगी।