HypoPG في PostgreSQL للمحترف: اختبر الـ Index قبل ما يقفل جدولك 6 ساعات

قبل ما نعمل CREATE INDEX حقيقي وننتظر 4 ساعات، نختبر الـ Index بـ HypoPG:

الفرق الجوهري هنا: الـ hypothetical index اتعمل في 80 مللي ثانية. الـ CREATE INDEX الحقيقي بـ CONCURRENTLY أخد 4 ساعات و 12 دقيقة على نفس الجدول، مع زيادة 38 جيجا في حجم القرص. لو الـ Planner ما اختارش الـ hypothetical، يبقى عرفت إن CREATE INDEX الحقيقي مكنش هيتفعّل أصلاً.

اختبار 3 indexes متنافسة في دقيقة واحدة

السيناريو الأقوى لـ HypoPG: لما يكون عندك أكثر من ترتيب أعمدة محتمل، وعايز تعرف أيهم أرخص بدون ما تبني 3 indexes حقيقية:

أرقام من إنتاج فعلي

على API بـ 18,400 طلب/دقيقة فوق PostgreSQL 16 على AWS r6g.2xlarge، اختبرنا 7 indexes مرشحة بـ HypoPG في 14 دقيقة. الـ Planner اختار 2 منهم فقط؛ الـ 5 التانيين بقيوا "موجودين" في الـ session بس مفيش query استخدمهم.

• زمن الاختبار الكامل لـ 7 indexes: 14 دقيقة.
• CREATE INDEX الفعلي للـ 2 الناجحين بـ CONCURRENTLY: 5 ساعات و 38 دقيقة.
• التوفير: 11 ساعة downtime و 84 جيجا قرص كان هيتأكل على indexes ميتة.
• P95 latency على /orders endpoint: من 4.8 ثانية لـ 38 مللي ثانية.
• CPU utilization على الـ Primary DB: من 89% لـ 34% في ساعة الـ peak.

Trade-offs لازم تعرفها

1. HypoPG مبيقدّرش الـ I/O الحقيقي بدقة 100%. الـ Planner بيستخدم cost model نظري؛ الـ Index الحقيقي ممكن يكون أبطأ شوية بسبب bloat أو cache miss، أو أسرع بسبب fillfactor و buffer hit ratio. الفرق غالباً ±15% على الـ cost المتوقّع.
2. مفيش دعم كامل لكل أنواع الـ Index. HypoPG 1.4 يدعم B-tree و BRIN و Hash بشكل كامل. الدعم لـ GIN و GiST جزئي، و SP-GiST مش مدعوم في الـ Index Estimate حالياً.
3. الـ session-scoped. الـ hypothetical indexes بتختفي مع قفل الـ connection. لو بتشتغل من tool زي DBeaver فيه connection pooling، تأكّد إنك في نفس الـ session لما تشغّل الـ EXPLAIN.
4. الـ Estimate بيعتمد على pg_statistic. لو الـ stats قديمة أو الـ ANALYZE ما اشتغلش مؤخراً على الجدول، التقدير ممكن يبقى مضلل. شغّل ANALYZE orders; قبل ما تختبر.

متى لا تستخدم HypoPG

متستخدمهوش لو الجدول أقل من 5 مليون صف — CREATE INDEX CONCURRENTLY غالباً هياخد أقل من دقيقتين، التجربة الحقيقية أرخص من التقدير وأدق. كمان مفيش قيمة حقيقية على development DB صغيرة، لأن الـ Planner cost model بيتغيّر جذرياً مع حجم البيانات و الـ buffer cache المتاح.

لو الـ query شغّال على Partition محدد في جدول مُقسّم، اختبر الـ Index على الـ partition نفسه مش الجدول الأم. وأخيراً، لو الـ workload writes-heavy (أكثر من 60% INSERT/UPDATE/DELETE)، التركيز لازم يبقى على Write Amplification والـ Index Maintenance Cost، مش بس على Read Plans — وده HypoPG ما بيقيسوش.

الخطوة التالية

افتح الـ Production DB دلوقتي، شغّل CREATE EXTENSION hypopg; ثم اسحب أبطأ 3 queries من pg_stat_statements ورتّبهم بـ total_exec_time DESC. لكل query، اختبر Index هيبوثيتيكال بـ hypopg_create_index قبل ما تعمل CREATE INDEX حقيقي. لو الـ Planner ما اختارش الـ hypothetical، انت لقيت 4 ساعات downtime ما تستحقش.

مصادر

• HypoPG GitHub Repository — github.com/HypoPG/hypopg
• HypoPG Official Documentation v1.4 — hypopg.readthedocs.io
• PostgreSQL 16 Documentation, EXPLAIN — postgresql.org/docs/16/sql-explain.html
• PostgreSQL 16 Documentation, CREATE INDEX CONCURRENTLY — postgresql.org/docs/16/sql-createindex.html
• Julien Rouhaud, "HypoPG: Hypothetical Indexes for PostgreSQL", PGCon 2015 — pgcon.org/2015/schedule/events/870.en.html
• PostgreSQL System Catalogs (pg_class, pg_index, pg_statistic) — postgresql.org/docs/16/catalogs.html
• pg_stat_statements Module Documentation — postgresql.org/docs/16/pgstatstatements.html