2012-12-06 12 views
6

शीर्षक के रूप में, मैं थोड़ी देर के लिए खोज कर रहा हूं और कोई जवाब नहीं ढूंढ पाया। यह केवल कुंजी बताता है और यह 8.4535 से अधिक नहीं हो सकता है जब यह 8.4 पर है, लेकिन 9.0 दस्तावेज पर इसका उल्लेख नहीं किया जा रहा है।PostgreSQL 9.0+ hstore के लिए आकार सीमा क्या है?

+0

मेरा अनुमान है कि यह अब एक कॉलम (यानी 1 जीबी) के आकार से सीमित है - लेकिन फिर यह सिर्फ एक अनुमान है। पोस्टग्रेस मेलिंग सूची पर आपको इस प्रश्न को पोस्ट करने में अधिक भाग्य हो सकता है। –

उत्तर

14

hstore एक varlena है, और TOAST एड फ़ील्ड के अधिकतम आकार, लगभग 1 जीबी तक सीमित है।

मैं अनुशंसा नहीं करता कि आप आकार के पास कहीं भी जाएं। प्रदर्शन भयानक होगा। प्रत्येक बार जब आप पंक्ति को अपडेट करते हैं - hstore फ़ील्ड वाली पंक्तियों सहित - PostgreSQL को पंक्ति की एक नई प्रति लिखनी होगी। कहने की जरूरत नहीं है, गीगाबाइट पंक्तियों के साथ जो मजेदार नहीं होने वाला है।

यदि आप सभी चाबियाँ/मान पढ़ रहे हैं तो प्रदर्शन पढ़ें ठीक है, लेकिन यदि आप चुनिंदा रूप से केवल कुछ कुंजियों/मानों को पढ़ रहे हैं, तो hstore पहुंच से पहले de-TOAST एड होना चाहिए।

अपने डिज़ाइन और केस का उपयोग किए बिना अधिक विशिष्ट सलाह देना मुश्किल है; इस प्रश्न के क्यों

+0

वैसे मैं बस सीमा जानना चाहता हूं, और आपके उत्तर के लिए धन्यवाद, यह काफी उपयोगी है। तो जब आप फ़ील्ड लिखते हैं तो वास्तव में एक क्रमबद्धता होती है? ऐसा लगता है कि वास्तविक नोएसक्यूएल स्टोरेज की तुलना में ऐसा कुछ शानदार नहीं है। –

+0

@ गुडविल 'hstore' उपयोगी है, लेकिन यह डेटाबेस-इन-ए-फील्ड नहीं है। मैंने हाल ही में इसके बारे में कुछ प्रश्न देखे हैं जो सुझाव देते हैं कि लोग एकल 'hstore' फ़ील्ड में पूरे तेज़-बदलते डेटा सेट को स्टोर करने का प्रयास करने पर विचार कर रहे हैं। यह एक भयानक विचार है। 'hstore' अक्सर ईएवी-संरचित डेटा को संग्रहीत करने या JSON/XML आदि का उपयोग करने का एक अच्छा विकल्प है, लेकिन यह "डेटाबेस" स्तर से "दस्तावेज़" पर अधिक है। यदि डेटा तेजी से बदल रहा है तो भी ईएवी बेहतर हो सकता है। –

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^