Table Partitioning في PostgreSQL للمتوسط: من 4.2 ثانية لـ 12ms على جدول 80 مليون صف

بعد النقل، الـ query اللي كان بياخد 4.2 ثانية:

الـ Planner بيستبعد 82 partition ويفتح اتنين بس (orders_2026_04 وorders_2026_05). الزمن نزل من 4,237ms لـ 12.4ms على نفس السيرفر (db.r6g.xlarge، 32GB RAM، NVMe SSD). الأرقام دي مقاسة من إنتاج e-commerce بـ 24,000 طلب يومي.

أتمتة إنشاء Partitions بـ pg_partman

إنشاء partition جديد كل شهر يدويًا = حادثة منتظرة. الحل: pg_partman extension. سطر واحد بيخلّي PostgreSQL يعمل partition الشهر القادم تلقائيًا قبلها بـ 7 أيام:

الـ Trade-offs اللي محدش بيقولك عليها

1. كل query لازم يحتوي partition key في WHERE. لو نسيت created_at، PostgreSQL هيفتح كل الـ 84 partition ويعمل scan على الجدول الأصلي. النتيجة أبطأ من قبل partitioning.
2. UNIQUE constraints لازم تحتوي partition key. ده معناه إنك مش تقدر تعمل UNIQUE (email) بسهولة. لازم تكون UNIQUE (email, created_at) أو تستخدم جدول reference منفصل.
3. Foreign keys من جداول تانية للـ parent محدودة. PostgreSQL 12+ بيدعمها، بس مع overhead. fix شائع: استخدم FK للـ child partition مباشرة لو ممكن.
4. Vacuum و Analyze بيشتغلوا لكل partition منفصل. ده غالبًا ميزة (تفرّق الـ load)، لكن أحيانًا بيلخبط autovacuum scheduler. راقب pg_stat_user_tables بانتظام.

متى Partitioning بيكون كارثة

متعملش partitioning لو الجدول أقل من 10 مليون صف. الـ overhead الإداري والـ planning time بيلغي أي مكسب. على جدول 2 مليون صف، Partial Index على created_at مع WHERE created_at > CURRENT_DATE - INTERVAL '90 days' بيدّيك نفس النتيجة بربع التعقيد.

كمان متعملوش لو الـ queries بتاعتك بتفلتر على عمود مش الـ partition key. مثلاً جدول users اللي بيتفلتر دايمًا بـ email أو id، partitioning على created_at هيضرّك مش هيفيدك.

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

افتح أبطأ 5 queries عندك من pg_stat_statements. لو كلهم على نفس جدول كبير وكلهم بيستخدمون نفس العمود الزمني في WHERE، انت candidate مثالي للـ partitioning. ابدأ بـ partition شهري واحد على بيئة staging، قِس الفرق بـ EXPLAIN ANALYZE قبل وبعد، وبعدها فكّر في الإنتاج. لو ظهرت أرقام مختلفة، ابعتلي الـ EXPLAIN — في الغالب الـ planner مش بيعمل pruning صح وفيه إعداد ناقص.

المصادر

• PostgreSQL 16 Documentation — Chapter 5.11 Table Partitioning: postgresql.org/docs/16/ddl-partitioning.html
• pg_partman GitHub — pgpartman/pg_partman v5.1.0 (2024)
• PostgreSQL Release Notes 16 — Performance improvements in partition pruning
• Crunchy Data Blog — "Partitioning in PostgreSQL: Real-world benchmarks" (2024)
• AWS RDS PostgreSQL Best Practices — re:Invent 2023 talk DAT304