🥇 PostgreSQL استفسار کے منصوبوں کو اور بھی آسانی سے سمجھنا

ڈیڑھ سال پہلے ہم نے پیش کیا explain.tensor.ru - عوام استفسار کے منصوبوں کو تجزیہ کرنے اور دیکھنے کے لیے خدمت PostgreSQL پر۔

پچھلے مہینوں میں ہم نے اس کے بارے میں کیا ہے۔ PGConf.Russia 2020 میں رپورٹ، ایک خلاصہ تیار کیا۔ ایس کیو ایل کے سوالات کو تیز کرنے سے متعلق مضمون ان سفارشات کی بنیاد پر جو یہ دیتا ہے... لیکن سب سے اہم بات، ہم نے آپ کے تاثرات اکٹھے کیے اور حقیقی استعمال کے معاملات کو دیکھا۔

اور اب ہم آپ کو ان نئی خصوصیات کے بارے میں بتانے کے لیے تیار ہیں جنہیں آپ استعمال کر سکتے ہیں۔

مختلف پلان فارمیٹس کے لیے سپورٹ

درخواست کے ساتھ لاگ سے منصوبہ بنائیں

کنسول سے براہ راست، ہم پورے بلاک کو منتخب کرتے ہیں، لائن سے شروع کرتے ہوئے سوال کا متنتمام معروف جگہوں کے ساتھ:

        Query Text: INSERT INTO  dicquery_20200604  VALUES ($1.*) ON CONFLICT (query)
                           DO NOTHING;
        Insert on dicquery_20200604  (cost=0.00..0.05 rows=1 width=52) (actual time=40.376..40.376 rows=0 loops=1)
          Conflict Resolution: NOTHING
          Conflict Arbiter Indexes: dicquery_20200604_pkey
          Tuples Inserted: 1
          Conflicting Tuples: 0
          Buffers: shared hit=9 read=1 dirtied=1
          ->  Result  (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)

... اور کاپی کی گئی ہر چیز کو پلان کے لیے براہ راست فیلڈ میں پھینک دیں، بغیر کچھ الگ کیے:

آؤٹ پٹ پر، ہمیں الگ کیے گئے پلان پر بونس بھی ملتا ہے۔ سیاق و سباق کا ٹیب، جہاں ہماری درخواست پوری شان کے ساتھ پیش کی گئی ہے:

JSON اور YAML

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM pg_class;

"[
  {
    "Plan": {
      "Node Type": "Seq Scan",
      "Parallel Aware": false,
      "Relation Name": "pg_class",
      "Alias": "pg_class",
      "Startup Cost": 0.00,
      "Total Cost": 1336.20,
      "Plan Rows": 13804,
      "Plan Width": 539,
      "Actual Startup Time": 0.006,
      "Actual Total Time": 1.838,
      "Actual Rows": 10266,
      "Actual Loops": 1,
      "Shared Hit Blocks": 646,
      "Shared Read Blocks": 0,
      "Shared Dirtied Blocks": 0,
      "Shared Written Blocks": 0,
      "Local Hit Blocks": 0,
      "Local Read Blocks": 0,
      "Local Dirtied Blocks": 0,
      "Local Written Blocks": 0,
      "Temp Read Blocks": 0,
      "Temp Written Blocks": 0
    },
    "Planning Time": 5.135,
    "Triggers": [
    ],
    "Execution Time": 2.389
  }
]"

یہاں تک کہ بیرونی اقتباسات کے ساتھ، بطور pgAdmin کاپیاں، یہاں تک کہ بغیر بھی - ہم ایک ہی فیلڈ میں پھینک دیتے ہیں، آؤٹ پٹ خوبصورتی ہے:

اعلی درجے کی تصور

منصوبہ بندی کا وقت / عمل درآمد کا وقت

اب آپ بہتر طور پر دیکھ سکتے ہیں کہ استفسار پر عمل کرتے وقت اضافی وقت کہاں گیا:

I/O ٹائمنگ

بعض اوقات آپ کو ایسی صورتحال سے نمٹنا پڑتا ہے جہاں وسائل کے لحاظ سے ایسا لگتا ہے کہ بہت زیادہ پڑھا اور لکھا نہیں گیا تھا، لیکن ایسا لگتا ہے کہ پھانسی کا وقت کسی وجہ سے بے ترتیبی سے زیادہ ہے۔

یہاں یہ کہنا ضروری ہے:اوہ، شاید، اس وقت سرور پر ڈسک بہت زیادہ لوڈ ہو گئی تھی، اسی لیے اسے پڑھنے میں اتنا وقت لگا!"لیکن کسی نہ کسی طرح یہ بہت درست نہیں ہے …

لیکن یہ بالکل قابل اعتماد طریقے سے طے کیا جا سکتا ہے. حقیقت یہ ہے کہ PG سرور کے کنفیگریشن آپشنز میں سے ہیں۔ track_io_timing:

وقتی I/O آپریشنز کو فعال کرتا ہے۔ یہ ترتیب بطور ڈیفالٹ غیر فعال ہے، کیونکہ اس کے لیے آپریٹنگ سسٹم کو موجودہ وقت کے بارے میں مسلسل استفسار کرنے کی ضرورت ہوتی ہے، جو کچھ پلیٹ فارمز پر چیزوں کو نمایاں طور پر سست کر سکتا ہے۔ آپ اپنے پلیٹ فارم پر وقت کے اوور ہیڈ کا اندازہ لگانے کے لیے pg_test_timing یوٹیلیٹی استعمال کر سکتے ہیں۔ I/O کے اعدادوشمار pg_stat_database ویو کے ذریعے حاصل کیے جا سکتے ہیں، EXPLAIN آؤٹ پٹ میں (جب BUFFERS پیرامیٹر استعمال کیا جاتا ہے) اور pg_stat_statements منظر کے ذریعے۔

یہ اختیار مقامی سیشن میں بھی فعال کیا جا سکتا ہے:

SET track_io_timing = TRUE;

ٹھیک ہے، اب سب سے اچھی بات یہ ہے کہ ہم نے اس ڈیٹا کو سمجھنا اور ظاہر کرنا سیکھ لیا ہے، عمل درآمد کے درخت کی تمام تبدیلیوں کو مدنظر رکھتے ہوئے:

یہاں آپ دیکھ سکتے ہیں کہ عمل درآمد کے کل وقت کے 0.790ms میں سے، 0.718ms نے ڈیٹا کا ایک صفحہ پڑھا، 0.044ms - اسے لکھنا، اور باقی تمام مفید سرگرمیوں پر صرف 0.028ms خرچ کیا گیا!

PostgreSQL 13 کے ساتھ مستقبل

نیا کیا ہے اس کے مکمل جائزہ کے لیے، دیکھیں ایک تفصیلی مضمون میں، اور ہم خاص طور پر منصوبوں میں تبدیلیوں کے بارے میں بات کر رہے ہیں۔

پلاننگ بفرز

شیڈیولر کے لیے مختص وسائل کا حساب کتاب دوسرے پیچ میں ظاہر ہوتا ہے جو pg_stat_statements سے متعلق نہیں ہے۔ BUFFERS آپشن کے ساتھ EXPLAIN منصوبہ بندی کے مرحلے کے دوران استعمال ہونے والے بفرز کی تعداد کی اطلاع دے گا:
 Seq Scan on pg_class (actual rows=386 loops=1)
   Buffers: shared hit=9 read=4
 Planning Time: 0.782 ms
   Buffers: shared hit=103 read=11
 Execution Time: 0.219 ms

بڑھتی ہوئی ترتیب

ایسی صورتوں میں جہاں کئی کلیدوں (k1, k2, k3…) کے ذریعے ترتیب دینے کی ضرورت ہوتی ہے، منصوبہ ساز اب یہ جاننے کا فائدہ اٹھا سکتا ہے کہ ڈیٹا پہلے ہی کئی پہلی کلیدوں (جیسے k1 اور k2) کے ذریعے ترتیب دیا گیا ہے۔ اس صورت میں، آپ تمام ڈیٹا کو نئے سرے سے ترتیب نہیں دے سکتے، لیکن k1 اور k2 کی یکساں قدروں کے ساتھ یکے بعد دیگرے گروپس میں تقسیم کر سکتے ہیں، اور کلیدی k3 کے ذریعے انہیں "دوبارہ ترتیب" کر سکتے ہیں۔

اس طرح، پوری چھانٹی ایک چھوٹے سائز کی کئی لگاتار چھانٹیوں میں ٹوٹ جاتی ہے۔ یہ مطلوبہ میموری کی مقدار کو کم کرتا ہے، اور آپ کو تمام چھانٹی مکمل ہونے سے پہلے پہلا ڈیٹا واپس کرنے کی بھی اجازت دیتا ہے۔
 Incremental Sort (actual rows=2949857 loops=1)
   Sort Key: ticket_no, passenger_id
   Presorted Key: ticket_no
   Full-sort Groups: 92184 Sort Method: quicksort Memory: avg=31kB peak=31kB
   ->  Index Scan using tickets_pkey on tickets (actual rows=2949857 loops=1)
 Planning Time: 2.137 ms
 Execution Time: 2230.019 ms

UI/UX میں بہتری

اسکرین شاٹس ہر جگہ ہیں!

اب ہر ٹیب پر جلدی کرنے کا موقع ہے۔ ٹیب کا اسکرین شاٹ کلپ بورڈ پر لیں۔ ٹیب کی پوری چوڑائی اور گہرائی کے لیے - "نظر" دائیں طرف:

دراصل، اس اشاعت کے لیے زیادہ تر تصاویر اس طرح حاصل کی گئی تھیں۔

نوڈس پر سفارشات

ان میں سے نہ صرف زیادہ ہیں، بلکہ ہر ایک کے بارے میں آپ کر سکتے ہیں۔ مضمون کو تفصیل سے پڑھیںلنک پر عمل کرتے ہوئے:

آرکائیو سے ہٹایا جا رہا ہے۔

بعض نے استطاعت طلب کی ہے۔ "بالکل" حذف کریں یہاں تک کہ ایسے منصوبے جو محفوظ شدہ دستاویزات میں شائع نہیں ہوئے ہیں - براہ کرم، صرف متعلقہ آئیکن پر کلک کریں:

ٹھیک ہے، آئیے یہ نہ بھولیں کہ ہمارے پاس ہے۔ حمائتی جتھہجہاں آپ اپنی رائے اور تجاویز لکھ سکتے ہیں۔

ماخذ: www.habr.com

PostgreSQL استفسار کے منصوبوں کو اور بھی آسانی سے سمجھنا