Postgres 18 جاب async I/O بـ 3× throughput — القرار بالظبط متى تهاجر

Postgres 18 async I/O: لمّا قاعدة البيانات بقت شغلها parallel حقيقي

لو الـ DB بتاعتك بتاخد ثانيتين في query تحت read-heavy workload، النسخة 18 بتغيّر المعادلة بالظبط. async I/O أصلي على Linux عبر io_uring، وskip scan بيقلّل عدد الـ index passes، وتحسينات موثّقة في vacuum وbackup. القرار مش "اعمل upgrade على طول"، القرار بالظبط: إمتى الأرقام دي بتفرق في شغلك، وإمتى الترحيل overkill مش مبرّر.

المشكلة باختصار

في النسخ الأقدم من Postgres، القراءات من الديسك كانت synchronous بالكامل. يعني كل page fetch بيقفل الـ worker process لحد ما الـ I/O يرجع من الـ storage. على NVMe محلي سريع، ده مش مشكلة كبيرة في OLTP. لكن على cold cache، أو storage متوسط، أو analytics queries بتمر على جداول كبيرة، بتخسر زمن ملحوظ في الانتظار.

Postgres 18 نزل رسميًا في 25 سبتمبر 2025 وبيجيب AIO كـ subsystem جديد في الـ core. على Linux بيستخدم io_uring، وعلى بقية الأنظمة بيستخدم worker processes. النتيجة الموثّقة في release notes الرسمية: تحسّن throughput يوصل لـ 3× على sequential scans، و2–2.5× على bitmap heap scans في الـ benchmarks الداخلية.

ليه async I/O بيفرق بالظبط

الفكرة إن Postgres دلوقتي يقدر يبعث عدة I/O requests في نفس الوقت، ويستفيد من الوقت ده في حساب execution plan steps تانية بدل ما يقعد ينتظر. ده معناه استغلال أفضل للـ CPU، وتقليل محسوس لوقت الـ wait على workloads فيها scans ثقيلة.

Skip Scan كمان ميزة جديدة مهمة. لو عندك index على (tenant_id, created_at) وبتعمل query بـ created_at لوحده، Postgres 18 هيقدر يستخدم الـ index ده بكفاءة بدل ما يعمل sequential scan على الجدول كله. في اختبارات EDB المنشورة، الفرق وصل لـ 180× في حالات محددة (جدول 10M rows، تصفية على column ثاني).

الخطوات قبل ما تهاجر

1. اتأكد إن الـ kernel عندك >= 5.1 لو عايز io_uring (Ubuntu 22.04+ أو RHEL 9 بيوفّروا ده افتراضيًا).
2. اعمل full backup، واتأكد من restore test حقيقي قبل الترحيل. مش snapshot بس.
3. استخدم pg_upgrade مع --link لترحيل سريع، لكن متنساش --check الأول.
4. اضبط io_method في postgresql.conf — القيمة الافتراضية worker؛ غيّرها لـ io_uring لو Linux حديث.
5. راقب الأرقام الجديدة في pg_stat_io اللي اتوسّع في 18 بأعمدة إضافية عن read/write timings.

# ترحيل نموذجي من 17 إلى 18 مع فحص أولي
pg_upgrade \
  --old-datadir=/var/lib/postgresql/17/main \
  --new-datadir=/var/lib/postgresql/18/main \
  --old-bindir=/usr/lib/postgresql/17/bin \
  --new-bindir=/usr/lib/postgresql/18/bin \
  --link --check

# بعد نجاح الترحيل، فعّل io_uring
echo "io_method = 'io_uring'" >> /etc/postgresql/18/main/postgresql.conf
echo "io_max_concurrency = 32" >> /etc/postgresql/18/main/postgresql.conf
systemctl restart postgresql@18-main