وضاحت اور تجزیہ کریں۔

کیا آپ نے کبھی سوچا ہے کہ ڈیٹا بیس choose کیسے کرتا ہے کہ آپ نے ابھی جو اچھا انڈیکس بنایا ہے اسے استعمال کیا جائے؟ جیسے ہی آپ کسی استفسار پر Enter کو دباتے ہیں (کہتے ہیں کہ ایک زنجیروں میں بند گروپ کے ساتھ ایک طویل شمولیت)، Query Planner سوال کو آگے بڑھانے کے لیے درجنوں حکمت عملیوں کا حساب لگاتا ہے اور نظریہ کے لحاظ سے، سب سے تیز رفتار ہونے کے لیے اسے چنتا ہے۔

لیکن ایک ڈویلپر کے طور پر، آپ کو Query Planner کے تاریک ذہن کے اندر دیکھنے کے قابل ہونے کی ضرورت ہے۔

وضاحت کریں۔

یہ جاننے کے لیے کہ منصوبہ ساز کس طرح آگے بڑھنے کا ارادہ رکھتا ہے، اپنے استفسار کے آغاز میں صرف جادوئی لفظ EXPLAIN ڈالیں۔

EXPLAIN SELECT * FROM orders WHERE status = 'delivered';

نتیجہ احکامات نہیں ہو گا! اس کے بجائے، آپ کو آؤٹ پٹ میں پلان نظر آئے گا (تخمینے کے اعدادوشمار کے ساتھ):

Seq Scan on orders  (cost=0.00..25.88 rows=15 width=40)
  Filter: (status = 'delivered'::text)

یہ ہمیں بتاتا ہے:

1. منصوبہ ساز ایک Seq Scan (بروٹ، پوری ڈسک کی ترتیب وار پڑھنا) استعمال کرے گا۔ اربوں کے آرڈر ہوں تو برا۔
2. اس کا تخمینہ ہے کہ ~ 15 قطاریں واپس کی جائیں گی، اور پہلے سے بھری ہوئی CPU سائیکلوں میں "لاگت" کا حساب لگاتا ہے۔

تجزیہ کی وضاحت کریں۔

جب کہ EXPLAIN الگورتھمک اندازوں پر انحصار کرتا ہے (ڈیٹا پر پچھلے چند گھنٹوں میں شمار کیے گئے عالمی اعدادوشمار کی بنیاد پر)، EXPLAIN ANALYZE حقیقت میں استفسار کو چلاتا ہے (اور مکمل منطقی نتائج کا انتظار کرتا ہے)، ریاضیاتی طور پر مطلق الفاظ میں حقیقی گزرے ہوئے وقت کا موازنہ کرتا ہے۔

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 90;

Index Scan using idx_orders_cust on orders  (cost=0.15..8.13 rows=4 width=40) (actual time=0.012..0.015 rows=4 loops=1)
  Index Cond: (customer_id = 90)
Planning Time: 0.081 ms
Execution Time: 0.033 ms

ہورے! یہاں آپ کو معلوم ہوگا کہ ڈیٹا بیس نے ہمارے ثانوی idx_orders_cust انڈیکس پر ایک انڈیکس اسکین لاگو کرنے کا فیصلہ کیا ہے، جس میں ایک سیکنڈ کے ہزارویں حصے کا مائکروسکوپک عمل وقت لیا جائے گا، لاکھوں قطاروں کو چھوڑ دیا جائے گا۔

آپ کی باری

سچی میٹرکس حاصل کرنا