PostgreSQL प्रदर्शन और क्वेरी अनुकूलन · पाठ

Parallelism अक्षम होने का निदान

उन functions, locks और settings की पहचान करें जो चुपचाप serial execution लागू कर देते हैं।

पाठ 4, कुल 4 में से13 चरण

Parallelism अक्षम होने का निदान, CoddyKit पर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह PostgreSQL प्रदर्शन और क्वेरी अनुकूलन सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

जब योजना serial हो जाए

आप समानांतर sequential scan की अपेक्षा करते हैं, लेकिन EXPLAIN साधारण serial योजना दिखाता है। planner के cost model को दोष देने से पहले यह समझें कि PostgreSQL में कई कठोर अवरोध हैं, जो बिना सूचना के समानांतरता को पूरी तरह रोक देते हैं।

कुछ सेटिंग्स होती हैं (अधिकतम worker की संख्या 0, या कम parallel_setup_cost का अब भी बहुत अधिक होना)।
कुछ query का आकार होता है (समानांतरता-असुरक्षित functions, write CTEs)।
कुछ runtime से संबंधित होते हैं (कोई worker slot खाली न होना या locks का लगा होना)।

इस lesson में हमारा काम है: व्यवस्थित रूप से पता लगाना कि कौन-सा अवरोध सक्रिय हुआ।

पहली जाँच: EXPLAIN ANALYZE

सबसे पहले पुष्टि करें कि समानांतरता दिखाई भी दी या नहीं। समानांतर योजना में समानांतर-जागरूक scan के ऊपर Gather (या Gather Merge) node होता है। यदि आपको केवल साधारण Seq Scan दिखाई दे, तो कोई worker भी उपयोगी नहीं माना गया।

Workers Planned और Workers Launched lines बताती हैं कि planner worker चाहता था या नहीं और runtime पर उसे वास्तव में worker मिले या नहीं — ये दो बिल्कुल अलग विफलताएँ हैं।

EXPLAIN (ANALYZE, VERBOSE, BUFFERS)
SELECT count(*)
FROM orders
WHERE amount > 100;

-- Look for:
--   Gather  (cost=...)
--     Workers Planned: 2
--     Workers Launched: 2
--     ->  Parallel Seq Scan on orders

नियोजित बनाम शुरू किए गए worker: विफलता के दो प्रकार

इन दोनों संकेतों में ठीक-ठीक अंतर करें:

Workers Planned: 0 — planner ने तय किया कि समानांतरता अवैध है या इसके लाभ पर्याप्त नहीं हैं। यह planning-time अवरोध है (सेटिंग्स, समानांतरता-असुरक्षित query, cost)।
Workers Planned: 2, Workers Launched: 0 — योजना समानांतर है, लेकिन execution के समय कोई worker slot खाली नहीं था। यह runtime पर संसाधन समाप्त होने की समस्या है।

इन दोनों को भ्रमित करने से घंटों का समय नष्ट होता है। कोई अनुमान बनाने से पहले हमेशा दोनों lines पढ़ें।

अवरोध 1: Worker settings

Workers Planned: 0 का सबसे सामान्य कारण configuration है। पहले इन तीन की जाँच करें:

max_parallel_workers_per_gather — यदि 0 है, तो queries के लिए समानांतरता वैश्विक रूप से बंद है। यही सबसे प्रमुख कारण है।
max_parallel_workers — pool का आकार; यह > 0 और ≤ max_worker_processes होना चाहिए।
max_worker_processes — सभी background worker के लिए पूर्ण अधिकतम सीमा।

इनकी एक साथ जाँच करें:

SELECT name, setting, source
FROM pg_settings
WHERE name IN (
  'max_parallel_workers_per_gather',
  'max_parallel_workers',
  'max_worker_processes',
  'max_parallel_maintenance_workers'
);

अवरोध 2: Table का आकार और cost thresholds

Worker सक्षम होने पर भी planner समानांतरता अस्वीकार कर देता है, जब relation बहुत छोटी लगती है। दो settings इसे नियंत्रित करती हैं:

min_parallel_table_scan_size (डिफ़ॉल्ट 8MB) — इससे छोटी heap को कभी समानांतर रूप से scan नहीं किया जाता।
min_parallel_index_scan_size (डिफ़ॉल्ट 512kB) — index scans के लिए यही नियम है।

इसके अलावा, parallel_setup_cost (डिफ़ॉल्ट 1000) और parallel_tuple_cost (डिफ़ॉल्ट 0.1) समानांतर योजनाओं पर अतिरिक्त लागत लगाते हैं; छोटे परिणामों में serial योजना cost के आधार पर आसानी से जीत जाती है। Table का वास्तविक आकार जाँचें:

SELECT pg_size_pretty(pg_relation_size('orders')) AS heap_size,
       (pg_relation_size('orders') / 1024.0 / 1024.0) AS heap_mb,
       current_setting('min_parallel_table_scan_size') AS min_scan;

अवरोध 3: समानांतरता-असुरक्षित functions

Query में कहीं भी मौजूद एक PARALLEL UNSAFE function पूरी योजना को serial बना देता है — कोई Gather नहीं होता। प्रत्येक function के पास समानांतर-सुरक्षा का एक label होता है:

SAFE — worker में चल सकता है।
RESTRICTED — योजना में आ सकता है, लेकिन केवल leader में, Gather के नीचे नहीं।
UNSAFE — पूरे statement के लिए समानांतरता पर रोक लगाता है।

User-defined functions डिफ़ॉल्ट रूप से UNSAFE होते हैं, जब तक आप उन्हें स्पष्ट रूप से mark न करें। जो कुछ भी लिखता है, sequences का उपयोग करता है या temporary tables तक पहुँचता है, वह unsafe है।

SELECT p.proname,
       p.proparallel  -- 's'=safe, 'r'=restricted, 'u'=unsafe
FROM pg_proc p
WHERE p.proname IN ('normalize_email', 'nextval', 'random', 'now')
ORDER BY p.proname;

अपने functions का audit करना

ऐसे UDFs खोजने के लिए जो बिना सूचना के समानांतरता बंद कर देते हैं, अपने स्वामित्व वाले प्रत्येक ऐसे function की सूची बनाएँ जिसे unsafe या restricted label मिला है। ऐसा function जो तर्क की दृष्टि से शुद्ध हो लेकिन default रूप से UNSAFE हो, अक्सर इसका छिपा हुआ कारण होता है।

यदि function वास्तव में केवल पढ़ता है और side effect से मुक्त है, तो planner को आगे बढ़ने देने के लिए उसे PARALLEL SAFE के रूप में फिर से घोषित करें।

SELECT n.nspname AS schema,
       p.proname AS function,
       CASE p.proparallel
         WHEN 's' THEN 'safe'
         WHEN 'r' THEN 'restricted'
         WHEN 'u' THEN 'unsafe'
       END AS parallel_safety
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname NOT IN ('pg_catalog', 'information_schema')
  AND p.proparallel <> 's'
ORDER BY 1, 2;

किसी Unsafe UDF label को ठीक करना

यदि आप पुष्टि कर लें कि function का कोई side effect नहीं है और वह कभी कुछ लिखता नहीं है, तो उसे safe mark करें ताकि वह Gather के नीचे चल सके। ईमानदार रहें: nextval() को call करने वाले, tables में बदलाव करने वाले या non-immutable session state का उपयोग करने वाले किसी भी function को restricted या unsafe ही रहना चाहिए।

वास्तव में unsafe function को safe mark करने से गलत परिणाम या worker crash हो सकते हैं — यह label संकेत नहीं, बल्कि एक अनुबंध है।

-- Only if the body is truly read-only and deterministic across workers:
ALTER FUNCTION normalize_email(text) PARALLEL SAFE;

-- Verify the new label:
SELECT proname, proparallel
FROM pg_proc
WHERE proname = 'normalize_email';

अवरोध 4: वे query shapes जो समानांतरता रोकती हैं

कुछ संरचनाएँ सेटिंग्स की परवाह किए बिना स्वाभाविक रूप से समानांतरता-प्रतिबंधित होती हैं:

डेटा-संशोधन कथन — INSERT/UPDATE/DELETE (समानांतर DML सीमित है; समानांतर लेखन का सामान्यतः उपयोग नहीं किया जाता)।
लेखन करने वाले / डेटा-संशोधन वाले CTE — लिखने वाला CTE क्रमिक निष्पादन को बाध्य करता है।
SELECT ... FOR UPDATE / FOR SHARE — लॉकिंग क्लॉज समानांतरता-प्रतिबंधित होते हैं।
PARALLEL UNSAFE वाले फ़ंक्शन के अंदर की क्वेरी, या ऐसी जगह कॉल की गई क्वेरी जहाँ बाहरी कथन पहले से ही लेखन कर रहा हो।
FULL OUTER JOIN ऐतिहासिक रूप से, और बाहरी समानांतर नोड को संदर्भित करने वाली सहसंबद्ध सबक्वेरी।

यदि आपकी क्वेरी में इनमें से कुछ भी है, तो कोई भी सेटिंग समानांतर योजना उत्पन्न नहीं करेगी।

-- This SELECT can be parallel:
EXPLAIN SELECT count(*) FROM orders WHERE amount > 100;

-- This one cannot — the locking clause is parallel-restricted:
EXPLAIN SELECT * FROM orders WHERE amount > 100 FOR UPDATE;

गेट 5: रनटाइम वर्कर समाप्ति

जब आपको Workers Planned: 4 दिखाई देता है, लेकिन Workers Launched: 1, तो योजनाकार सही था, लेकिन पूल खाली था। पूरे क्लस्टर का पूल max_parallel_workers द्वारा सीमित होता है, max_worker_processes से लिया जाता है, और autovacuum तथा अन्य समानांतर क्वेरी के साथ साझा किया जाता है।

समवर्ती निष्पादन के दौरान, क्वेरी में बचे हुए स्लॉट में से जो उपलब्ध हों उन्हें ले लेती हैं — कभी-कभी शून्य स्लॉट भी। प्रतिस्पर्धा की पुष्टि करने के लिए सक्रिय बैकएंड देखें:

SELECT pid, backend_type, state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE backend_type = 'parallel worker'
   OR query ILIKE '%Gather%'
ORDER BY backend_type;

गेट 6: लॉक और force_parallel_mode

दो अंतिम, आसानी से छूट जाने वाले गेट हैं:

भारी लॉक — यदि कोई बैकएंड परस्पर-विरोधी लॉक रखता है या उसके लिए प्रतीक्षा कर रहा है, तो निष्पादन क्रमिक हो सकता है; इसी तरह, ACCESS EXCLUSIVE लॉक के अधीन संबंध को अवरुद्ध रहते हुए समानांतर स्कैन नहीं मिलेगा। pg_locks को pg_stat_activity के साथ जोड़कर जाँचें।
debug_parallel_query (पहले force_parallel_mode) — परीक्षण के लिए GUC है। इसे on/regress पर सेट करने से तब भी Gather बाध्य होता है जब उसका कोई अर्थ न हो, जिससे वास्तविक निदान छिप सकता है। सामान्य जाँच के दौरान सुनिश्चित करें कि यह off हो।

SELECT name, setting
FROM pg_settings
WHERE name IN ('debug_parallel_query', 'force_parallel_mode');

-- Who is blocking a parallel scan?
SELECT l.pid, l.mode, l.granted, a.query
FROM pg_locks l
JOIN pg_stat_activity a ON a.pid = l.pid
WHERE l.relation = 'orders'::regclass
ORDER BY l.granted;

त्वरित जाँच: लक्षण का निदान

एक विश्लेषक EXPLAIN ANALYZE चलाता है और उसे Workers Planned: 4 दिखाई देता है, लेकिन Workers Launched: 0। सभी worker GUC शून्येतर हैं और तालिका 2 GB की है। सबसे संभावित कारण क्या है?

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन: निदान जाँच-सूची

यह पता लगाने के लिए कि समानांतरता क्यों अक्षम थी, ऊपर से नीचे की ओर जाँच करें:

दोनों पंक्तियाँ पढ़ें। Workers Planned: 0 = योजना-निर्माण गेट; Planned>0, Launched<Planned = रनटाइम समाप्ति।
सेटिंग्स: max_parallel_workers_per_gather (≠0), max_parallel_workers, max_worker_processes जाँचें।
आकार/लागत: तालिका min_parallel_table_scan_size से बड़ी हो; parallel_setup_cost छोटे परिणाम पर हावी न हो।
फ़ंक्शन: pg_proc में proparallel <> 's' खोजें; गलत लेबल वाले UDF ठीक करें।
क्वेरी का स्वरूप: लेखन, डेटा-संशोधन वाले CTE, FOR UPDATE लॉकिंग क्लॉज।
रनटाइम: खाली स्लॉट के लिए pg_stat_activity; अवरोधक के लिए pg_locks; पुष्टि करें कि debug_parallel_query = off है।

लक्षण को सही गेट से मिलाएँ, और मौन क्रमिक योजना रहस्य नहीं रहेगी।

शुरुआत निःशुल्क

एआई शिक्षक के साथ SQL सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 22
पाठ: 88

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “Parallelism अक्षम होने का निदान” पाठ निःशुल्क है?

हाँ — PostgreSQL प्रदर्शन और क्वेरी अनुकूलन अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “Parallelism अक्षम होने का निदान” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“Parallelism अक्षम होने का निदान” में मैं क्या सीखूँगा?

उन functions, locks और settings की पहचान करें जो चुपचाप serial execution लागू कर देते हैं। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ PostgreSQL प्रदर्शन और क्वेरी अनुकूलन का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या PostgreSQL प्रदर्शन और क्वेरी अनुकूलन शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“Parallelism अक्षम होने का निदान” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

Planner Parallel Plans कब चुनता है
Worker Counts और Gather Costs का समायोजन
Parallel Aggregation और Hash Joins
Parallelism अक्षम होने का निदान

← PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पर वापस जाएँ