PostgreSQL optimizer में 10 वर्षों के सुधार

 (rmarcus.info)
2 पॉइंट द्वारा GN⁺ 2024-04-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें

PostgreSQL optimizer में 10 वर्षों के सुधार

  • query optimization researcher के रूप में पिछले 10 वर्षों से PostgreSQL के परिष्कृत open source query optimizer का उपयोग करके शोध किया है
  • database पर काम शुरू करने के बाद यह जिज्ञासा हुई कि 10 वर्षों में PostgreSQL कितना सुधरा है
  • बदलावों के रिकॉर्ड और राय तो बहुत थीं, लेकिन ठोस empirical comparison नहीं मिला, इसलिए PostgreSQL 8 से 16 तक Join Order Benchmark (JOB) खुद चलाने का निर्णय लिया गया
  • हर database version के लिए 90वें percentile query latency को दर्ज किया गया

test environment configuration

  • Arch Linux के Docker container के भीतर GCC 13.2 का उपयोग करके PostgreSQL के हर version को build किया गया
  • query optimizer की quality मापने के लिए shared_buffers को 8GB पर सेट किया गया (इतना बड़ा कि पूरा database समा सके)
  • सभी versions के लिए work_mem को 8MB पर सेट किया गया
  • cache warm करने के लिए हर query को एक बार चलाया गया, फिर अतिरिक्त 5 बार चलाकर median latency दर्ज की गई

समग्र performance सुधार

  • PostgreSQL की tail performance में बड़ा सुधार हुआ, लेकिन version 13~16 कुल मिलाकर अपेक्षाकृत स्थिर रहे
  • version 8 और 16 की तुलना करने पर, PostgreSQL optimizer ने पिछले 10 वर्षों में tail latency को लगभग आधा कर दिया
  • पूरी query distribution की भी जाँच की जा सकती है (log scale देखें)

regression analysis के माध्यम से सुधार का मात्रात्मक आकलन

  • regression analysis का उपयोग करके यह जाँचा जा सकता है कि latency में गिरावट की slope सार्थक है या नहीं, और हर PostgreSQL version कितना सुधार लाता है, इसका मात्रात्मक आकलन किया जा सकता है
  • PostgreSQL major version number के विरुद्ध query latency का regression करने पर, PostgreSQL का हर नया major version औसतन Join Order Benchmark में 15% performance improvement लाता है
  • हालांकि, परिवर्तन को मापने के लिए linear model arguably a poor measure है

अतिरिक्त विचार

  • बेशक, ये सभी सुधार सिर्फ query optimizer की वजह से नहीं हैं। parallel worker से लेकर just-in-time (JIT) compilation तक, execution engine में हुए सुधार भी इसमें भूमिका निभाते हैं
  • यह जाँचना भी रोचक होगा कि JOB की हर query plan साल-दर-साल कैसे बदली है

मुख्य बिंदु

  • अपने database को upgrade करें! PostgreSQL 8 से 16 पर जाने से workload की tail latency में बड़ा सुधार हो सकता है
  • researchers को ध्यान रखना चाहिए कि PostgreSQL एक moving target है
    • learned query optimization research समय के साथ PostgreSQL के अलग-अलग versions से तुलना करती रही है
    • अगर पुरानी technique PostgreSQL को 30% बेहतर बनाती थी और नई technique 25% सुधार देती है, तो संभव है कि नई technique की तुलना पहले से अधिक शक्तिशाली PostgreSQL से हो रही हो

GN⁺ की राय

  • PostgreSQL लगातार performance सुधारता आया है, लेकिन हाल के versions में सुधार की गति कम होती दिखती है। इसकी एक वजह यह हो सकती है कि पहले ही काफी optimization हो चुका है। आगे के सुधार शायद अधिक सूक्ष्म क्षेत्रों पर केंद्रित होंगे

  • सिर्फ query optimizer ही नहीं, execution engine में सुधार भी performance gains में योगदान दे रहे हैं। parallel processing और JIT compilation जैसे कई पहलुओं में optimization किया गया है

  • यह प्रयोग Join Order Benchmark तक सीमित है, इसलिए वास्तविक कामकाजी वातावरण में performance improvement का असर workload के अनुसार अलग हो सकता है। अपने workload की प्रकृति के अनुसार benchmark करना बेहतर होगा

  • researchers को PostgreSQL version changes को ध्यान में रखना चाहिए। वही algorithm भी तुलना के लिए उपयोग किए गए PostgreSQL version के अनुसार relative performance improvement में अलग परिणाम दे सकता है

  • अगर आप PostgreSQL का पुराना version इस्तेमाल कर रहे हैं, तो upgrade पर गंभीरता से विचार किया जा सकता है। 10 साल पुराने version की तुलना में नए versions में स्पष्ट performance improvement हुआ है। बेशक, upgrade के साथ आने वाली compatibility जैसी समस्याओं को भी ध्यान में रखना होगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-19
Hacker News की राय

सारांश:

  • ऑप्टिमाइज़ेशन समस्याओं को अच्छी तरह हल करने के लिए cost से जुड़ा डेटा महत्वपूर्ण है। PostgreSQL में सुधार की काफी गुंजाइश है। खासकर syscall latency डेटा और foreign key statistics जैसी चीज़ों की कमी है।
  • बड़े पैमाने की queries के लिए deferred planning जैसी तकनीकों की ज़रूरत है, ताकि execution के दौरान plan बदला जा सके।
  • machine learning का उपयोग cost prediction model को बेहतर बनाने में करना उचित है। machine learning से सीधे query plan बनाना उचित नहीं है।
  • shared buffer को बहुत बड़ा रखकर सारा डेटा memory में चढ़ाकर benchmarking करना optimizer की वास्तविक performance का सही आकलन करना मुश्किल बना देता है.
  • JIT compiler अभी भी कई मामलों में सिर्फ performance degradation का कारण बनता है.
  • PostgreSQL version numbering 10 से बदल गई थी, इसलिए 8.x और 9.x versions को major versions मानकर performance trend का विश्लेषण करना भी दिलचस्प हो सकता है.
  • सिर्फ दिए गए graph से performance improvement trend को स्पष्ट रूप से देखना मुश्किल है। Tail latency में सुधार दिखता है, लेकिन बाकी metrics अलग-अलग हो सकते हैं.
  • बेहतरीन optimizer बनाना काफ़ी चुनौतीपूर्ण काम है.
  • यह जानने की जिज्ञासा है कि query optimization SQL स्तर पर है या algorithm स्तर पर.