Code With Somar

🧯 من مشاكل الـ Production #5 شو يعني Race Condition؟ مثال حقيقي من Ecommerce عندك قطعة وحدة بالمخزون: stock_quantity = 1 وصل طلبين بنفس اللحظة. Request A قرأ المخزون: 1 Request B قرأ المخزون: 1 الأول قال: متوفر ✅ والثاني قال: متوفر ✅ الاثنين كملوا الطلب. مبروك… بعت قطعة وحدة لشخصين 😅 هاي اسمها: Race Condition المشكلة مو إن شرط المخزون غلط. المشكلة إن عمليتي القراءة والتعديل ما كانوا محميين من التنفيذ المتزامن. لهيك Check مثل: stock > 0 مو كافي دائماً. ممكن تحتاج: Database Lock أو Atomic Update أو آلية مناسبة حسب الـ Flow. 📌 لما تكتب Backend Code، لا تتخيل Request واحد عم ينفذ الكود. بالـ Production ممكن عدة Requests يوصلوا لنفس السطر بنفس اللحظة. الكود الصحيح لمستخدم واحد… مو دائماً صحيح تحت الـ Concurrency. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

عطل فني في موقع فيسبوك التطبيق لسا شغال لكن الموقع واقف حاليا

🧯 من مشاكل الـ Production #4 ليش exists داخل Array Validation ممكن يصير كارثة؟ تخيل API تستقبل ترتيب 500 منتج: items.*.id وبالـ Validation كتبت: exists:products,id شكله طبيعي جداً. لكن حسب طريقة الـ Validation والـ Logic المستخدم، ممكن ينتهي فيك الموضوع بعمل Database Lookup لكل ID. 500 عنصر؟ ممكن تعمل مئات الاستعلامات فقط حتى تقول: “نعم، المنتجات موجودة.” هاي نفس روح مشكلة N+1… بس مو بالـ Eloquent Relations. بالـ Validation 😅 الحل ببعض الحالات أبسط: اجمع كل الـ IDs. اعمل Query واحد: WHERE id IN (...) جيب الـ IDs الموجودة. وبعدين قارن النتيجة مع الـ Input. 📌 لا تقيس كلفة الـ Validation بعدد أسطر الكود. Validation Rule من كلمة وحدة… ممكن يكون وراه مئات الـ Queries. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🧯 من مشاكل الـ Production #3 Redis سريع… بس ممكن تكون عم تستخدمه غلط 🚀 أول ما نحكي Redis، أول كلمة بتخطر ببالنا: Cache. Query بطيء؟ خزن النتيجة بـ Redis. API بطيء؟ Cache. صفحة ثقيلة؟ Cache 😅 بس المشكلة إن Redis مو زر اسمه: “خلّي السيستم أسرع” مثلاً تخيل إنك خزنت Product Object كامل بالـ Cache لمدة ساعة. خلال هالساعة تغير السعر. شو صار؟ الـ Database فيها: 1,000,000 IQD والـ Cache لسا فيها: 1,100,000 IQD الـ Redis هون شغال 100%. المشكلة بالـ Design. وهون بيجي السؤال الأصعب بالـ Caching: مو كيف أخزن البيانات؟ السؤال هو: متى أمسحها؟ هاي هي مشكلة: Cache Invalidation كل Data بتحطها بالـ Cache لازم تعرف شو الأحداث اللي بتخليها Stale. تغير السعر؟ تغير المخزون؟ تغير الخصم؟ تغير حالة المنتج؟ إذا نسيت Event واحد فقط، ممكن تعرض بيانات قديمة للمستخدم. والموضوع أخطر لما تحط TTL طويل وتقول: “بعد ساعة بتنحل لحالها.” لأنك عملياً عم تقول: عادي السيستم يكون غلط لمدة ساعة. 😅 📌 Redis سريع جداً. بس البيانات الغلط بسرعة عالية… لسا بيانات غلط. قبل ما تعمل Cache لأي شي، اسأل: مين مسؤول عن Invalidation؟ إذا ما عندك جواب واضح، غالباً أنت مو جاهز تعمل Cache لهاي البيانات. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🔥 Firebase Remote Config ما عاد مجاني بشكل غير محدود Google أعلنت عن تغيير مهم بتسعير Firebase Remote Config، وابتداءً من 1 سبتمبر 2026 رح تنتقل الخدمة إلى نموذج Pay-As-You-Go (PAYG)، يعني التسعير رح يصير حسب عدد طلبات الـ fetch اليومية. الخبر الجيد: في Free Tier بيغطي أول 100,000 fetch يومياً لكل Project مجاناً. 💰 التسعير الجديد: • من 0 إلى 100,000 fetch يومياً → مجاني • من 100,001 إلى 10,000,000 → $0.06 لكل 10,000 fetch • فوق 10,000,000 → $0.01 لكل 10,000 fetch 📅 المواعيد المهمة: • 1 سبتمبر 2026: بدء تطبيق نموذج التسعير الجديد • 1 ديسمبر 2026: انتهاء فترة السماح الأساسية وبدء احتساب الرسوم • ممكن تأجيل بدء الفوترة حتى 1 فبراير 2027 إذا تم الانتقال إلى Blaze Plan قبل 15 نوفمبر 2026 Google كمان بتنصح بربط المشروع مع Google Cloud Billing Account والانتقال إلى Blaze Plan، خصوصاً للمشاريع اللي ممكن تتجاوز الحد المجاني، لتجنب أي throttling محتمل والحصول على فترة سماح إضافية. بالنسبة لمعظم التطبيقات الصغيرة والمتوسطة، 100 ألف fetch يومياً ممكن يكون أكثر من كافي، لكن الموضوع بيعتمد بشكل كبير على طريقة إعداد fetch interval وعدد المستخدمين النشطين. إذا تطبيقك بيستخدم Remote Config، صار مهم تراجع: عدد الـ fetch requests اليومية، إعدادات الـ cache والـ minimum fetch interval، وطريقة استدعاء Remote Config داخل التطبيق. 📌 التغيير خاص بـ Firebase Remote Config Fetch Requests، ومو معناه إن كل خدمات Firebase صارت مدفوعة.

أخيرًا، Laravel صار يدعم Image Processing بشكل رسمي First-party، يعني معالجة الصور صارت جزءًا مباشرًا من الـ Framework بدل الاعتماد دائمًا على Packages خارجية. صار فيك تتعامل مع الصور المرفوعة مباشرة: $request->image('avatar') ->optimize() ->store('avatars'); وكمان معالجة صورة موجودة مسبقًا: Storage::image('avatars/avatar.png') ->cover(200, 200) ->toWebp() ->store('thumbnails'); الميزة بتدعم Configurable Drivers مثل: GD — Imagick — Cloudflare وكمان Immutable Transformations لتحويل وتعديل الصور بطريقة مرتبة وواضحة. النتيجة؟ كود أبسط، معالجة صور أسهل، وإمكانية Resize / Crop / Optimize / WebP Conversion مباشرة بأسلوب Laravel المعتاد.🔥

🧯 من مشاكل الـ Production #2 كيف صورة واحدة ممكن تعمل OOM وتضرب تطبيقك؟ عندك صورة حجمها على السيرفر: 500 KB بتقول: ممتاز، خفيفة جداً. بس حجم الملف مو هو نفسه حجم الصورة بالـ Memory. مثلاً صورة أبعادها: 4000 × 3000 لما التطبيق يفك ضغطها حتى يعرضها، ممكن تحتاج تقريباً: 4000 × 3000 × 4 bytes يعني حوالي: 48 MB بالـ RAM 😅 طيب تخيل عندك Product Grid فيه 10 صور مشابهة… نظرياً ممكن توصل لمئات الـ MB من الـ Memory. وهون ممكن يظهر: Out Of Memory (OOM) والتطبيق يضرب 💥 المشكلة إن المطور ممكن يروح يضغط الصور أكثر: 500 KB → 200 KB لكن الصورة لسا أبعادها: 4000 × 3000 يعني خففت الـ Network Size… بس بعد فك الصورة، استهلاك الـ Memory ممكن يضل ضخم. 📌 File Size ≠ Decoded Image Size إذا الصورة رح تنعرض داخل Card بحجم صغير، ما في سبب تفك صورة بدقة 4K كاملة بالـ Memory. بـ Flutter مثلاً، لازم تنتبه لأشياء مثل: cacheWidth cacheHeight وكمان الأفضل يكون عندك Image CDN يولد أحجام مناسبة حسب مكان عرض الصورة. الصورة اللي بالـ Product Card مو لازم تكون نفس الصورة اللي بالـ Product Details. أحياناً مشكلة الـ OOM مو Memory Leak… أحياناً أنت بكل بساطة عم تطلب من الموبايل يفك صور أكبر بكتير من اللي الشاشة محتاجتها. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

✅ UPDATE: Telegram's t.me Domain Has Been Restored

🧯 من مشاكل الـ Production #1 إذا اشتغلت Flutter، غالباً مرقت عليك هالمشكلة: عندك ListView أو GridView داخل SingleChildScrollView. Flutter بيعطيك مشكلة بالـ layout… فبتضيف: shrinkWrap: true و: NeverScrollableScrollPhysics() المشكلة بتنحل ✅ بس ممكن تكون خلقت مشكلة أكبر بدون ما تنتبه. الـ ListView بطبيعته Lazy. يعني إذا عندك 500 منتج، Flutter ما بيبني الـ 500 كلهم مباشرة. بيبني العناصر اللي ظاهرة عالشاشة، والعناصر القريبة منها. لكن لما تستخدم shrinkWrap: true، الـ List لازم تعرف حجمها الكامل حتى تحدد ارتفاعها. يعني Flutter ممكن يضطر يعمل Build و Layout لعدد ضخم من العناصر من البداية. 500 Product Cards؟ صور، أسعار، Discounts، Badges، Widgets… كلهم ممكن يدخلوا بعملية الـ Layout قبل ما المستخدم يوصل لعندهم أصلاً. والنتيجة: 🐌 فتح الصفحة بطيء 🧊 Scroll Jank 📈 استهلاك Memory أعلى 🔥 ضغط أكبر على الـ CPU والغريب إن الكود بيكون “شغال”. ما في Crash. ما في Exception. بس المستخدم بيقلك: “التطبيق تقيل.” الحل الأفضل بالقوائم الطويلة؟ استخدم: CustomScrollView مع: SliverList أو: SliverGrid وخلي Flutter يبني العناصر وقت الحاجة. 📌 مو كل كود حل مشكلة Layout يعني إنه حل صحيح للـ Production. أحياناً shrinkWrap: true بيحل المشكلة اللي قدامك… وبيخلق مشكلة Performance ما رح تشوفها إلا عند المستخدم. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

إذا لاحظت إن روابط t.me ما عم تفتح، فالمشكلة مو من موبايلك ولا من الإنترنت عندك. المشكلة صارت على مستوى الـ Domain Registry نفسه 👀 نطاق t.me دخل بحالة اسمها serverHold. طيب شو يعني هالحكي؟ 🤔 ببساطة، لما تحط الـ Registry دومين بحالة serverHold، الدومين بينشال من الـ Global DNS Resolution. يعني لما تكتب: t.me/channel الـ DNS أساساً ما عاد قادر يوصلك للسيرفر المرتبط بـ t.me. والنتيجة؟ كل روابط t.me Short Links ممكن تتعطل حول العالم 🌍 المثير للاهتمام إن المشكلة مو بسبب إن Telegram نسي يجدد الدومين 😅 حسب بيانات WHOIS: الدومين معمول من سنة 2010، ومسجل عن طريق GoDaddy، وصلاحيته ممتدة لحد سنة 2035. كمان الـ Name Servers لسا موجودين وعم يشيروا لبنية Google: ns-cloud-b1 → ns-cloud-b4.googledomains.com يعني إعدادات الـ DNS Delegation موجودة. بس هون النقطة المهمة 👇 الـ Registry عنده صلاحية أعلى من الـ DNS Provider. يعني حتى لو سيرفراتك شغالة، والـ Name Servers صحيحة، والـ Domain مدفوع لـ 9 سنين لقدام… الـ Registry بيقدر يقول: وقفوا هالدومين عن الـ Resolution. وهذا تقريباً اللي بتعمله حالة serverHold.

آكبر غلط منوقع فيه كلنا هو ضعف Observability ما فيك تصلح مشكلة أنت مو شايفها. إذا التطبيق بطيء، بس ما عندك أرقام واضحة، رح ترجع للتخمين: أي Query بطيئة؟ كم مرة اشتغلت؟ كم متوسط وقتها؟ هل في Locks؟ هل في Queries عم تفحص ملايين الصفوف؟ هل المشكلة من Query وحدة ولا من ضغط عام؟ بدون Monitoring، أنت فعلياً عم تشتغل بالعتمة. 💡 أهم شيء لازم تفعله: pg_stat_statements هاي الإضافة بتعطيك إحصائيات مهمة عن الاستعلامات، مثل: كم مرة اشتغل كل Query متوسط وقت التنفيذ إجمالي الوقت المستهلك عدد الصفوف المقروءة أو الراجعة أي Queries عم تستهلك أكبر وقت وكمان لازم تراقب: Slow Query Logs Locks عدد Connections استهلاك CPU/RAM حجم الجداول والـ Indexes Autovacuum activity ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

بـ PostgreSQL، لما تعمل UPDATE أو DELETE لسطر معين، الداتا بيز فعلياً ما بتحذفه فوراً من الهارد ديسك! هاد السطر القديم بيتحول لشي منسميه Dead Tuple (سطر ميت). مع الوقت وكترة التعديلات، هدول الأسطر الميتة بيتراكموا وبيعملوا مشكلة اسمها Bloat (تضخم وهمي). يعني حجم الجداول والـ Indexes بيكبر بشكل مبالغ فيه عالفاضي. شو نتيجة هالـ Bloat؟ 📉 الاستعلامات (Queries) بتصير أبطأ بكتير. 📉 الـ Indexes بتكبر بلا طعمة. 📉 استهلاك مساحة التخزين بيزيد. 📉 قراءة البيانات بتصير أثقل والأداء العام بينزل. هون بيجي دور الـ Vacuum . هاد الأمر بينظف الـ Dead Tuples وبيساعد PostgreSQL يحافظ على أداء مستقر. ولحسن الحظ، في نظام تلقائي اسمه Autovacuum بيعمل هالشي بالخلفية بدون ما تتدخل. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

😭😭

بما انه Google عم تجهز لإطلاق Android 17 كمبرمج موبايل و خصوصاً flutter في كم شغلة لازم تبلش تشتغل عليها و تخليها ببالك لتضمن مايطلعلك اي crash بالتطبيق تبعك 1- اختبر تطبيقك على Android 17 emulator: نزل نسخة أندرويد 17 وجرب تمشي بكل شاشات التطبيق. ركزوا كتير على الـ large screen layouts (الشاشات الكبيرة)، وضع الـ split-screen mode (تقسيم الشاشة)، والـ freeform windowing. جوجل عم تركز كتير على التابلت والأجهزة القابلة للطي، فمشان هيك لازم الـ UI تبعك يكون مرن وما يضرب. 2- شيك على الـ native plugins: إذا تطبيقك بيعتمد على بكجات بتستخدم reflection لتوصل لملفات نظام مخفية بالأندرويد، أو بتسحب native libraries بشكل ديناميكي.. لازم تنتبه! أندرويد 17 رح يفرض قيود أمنية صارمة، وأي بكج قديم أو ما عم يتحدث ممكن يوقفلك التطبيق فجأة. 3- حطوا الـ AppFunctions ببالكم: إذا تطبيقكم فيه أكشنز واضحة للمستخدم (متل إنشاء طلب، بحث، أو حجز)، صار الوقت تفكروا تبنوا Platform Channel لتربطوا كود Kotlin مميز بـ @AppFunction. ليش؟ لأنو لما جوجل تطلق ميزات Gemini الجديدة، رح يصير الذكاء الاصطناعي قادر ينفذ أوامر جوا تطبيقك مباشرة. هاد الشي بيعطيك ميزة تنافسية خرافية! 4- راجعوا استخدام الصلاحيات بتطبيقاتكم: إذا تطبيقك بيطلب صلاحية READ_CONTACTS (قراءة جهات الاتصال)، أو بيقرا رسائل الـ SMS مشان يتحقق من كود الـ OTP (وهي حركة كتير منعملها بتطبيقات المحاسبة والمتاجر)، لازم توقفوا هالحكي وتدوروا على بدائل. جوجل ما عاد تسمحلك تسحب كل رسائل المستخدم أو كل أرقامه. كبديل للـ OTP، استخدموا الـ SMS Retriever API اللي بيجيب الكود لحاله بدون ما ينتهك خصوصية المستخدم. ولجهات الاتصال، استخدموا الـ Contact Picker. أي مخالفة لهي الأمور ممكن تعرض تطبيقك للرفض على Google Play! 🚨 ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شركة Anthropic أعلنت إنها مددت فترة الوصول لنموذج الذكاء الاصطناعي Claude Fable 5 لكل المستخدمين المشتركين بالخطط المدفوعة (Paid plans). التمديد رح يكون مستمر لغاية 12 تموز (يوليو). فرصة ممتازة لتستفيدوا من قدرات المودل وتجربوه بمشاريعكم وتختبروا أداءه بكتابة الأكواد خلال هالكم يوم الإضافيين! 🔥 #AI #Anthropic #ClaudeFable5 #TechNews

تخيل Query علقت. أو Query ناطرة Lock على جدول، والجدول محجوز من عملية ثانية. إذا ما عندك Timeout، ممكن تضل العملية معلقة لفترة طويلة جداً. المشكلة إنها مو بس معلقة وخلاص. هي كمان ممكن تكون: حاجزة Connection مستهلكة موارد مانعة عمليات ثانية مسببة تراكم بالطلبات وراها مشاكل أكبر بالتطبيق لذلك لازم تحط حدود زمنية واضحة. أهم إعدادين: statement_timeout بيوقف أي استعلام إذا أخذ أكثر من مدة معينة. lock_timeout بيوقف الاستعلام إذا ظل ينتظر Lock أكثر من مدة معينة. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

أحياناً قاعدة البيانات تتأخر أو تتعطل لثواني. المشكلة مو هون. المشكلة لما التطبيق يكون مبرمج يعمل Retry فوراً وبلا حدود. يعني الطلب يفشل، فيعيد المحاولة مباشرة. يفشل مرة ثانية، يعيد مباشرة. ويضل يعيد بدون توقف. شو بيصير؟ بدل ما تساعد النظام يرجع، أنت بتزيد الضغط عليه. ولما PostgreSQL يبدأ يتعافى، بتوصله دفعة ضخمة من الطلبات المتراكمة بنفس اللحظة. وهون ممكن يرجع ينهار من جديد. هاي الحالة اسمها Thundering Herd. لهيك استخدم Exponential Backoff. يعني لا تعيد المحاولة فوراً. خلي في وقت انتظار بين كل محاولة ومحاولة. مثلاً: المحاولة الثانية بعد 1 ثانية الثالثة بعد 3 ثواني الرابعة بعد 10 ثواني وبعد عدد معين من المحاولات، توقف وارجع Error واضح. الأفضل كمان تضيف Jitter، يعني تأخير عشوائي بسيط، حتى ما كل الطلبات تعيد المحاولة بنفس اللحظة. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

في PostgreSQL، كل Connection جديد مو مجاني. كل اتصال بياخد جزء من الذاكرة وموارد من السيرفر. المشكلة بتكبر لما يكون عندك تطبيق شغال على أكثر من Instance أو Pod. مثلاً: عندك 100 Pod وكل Pod فاتح 20 Connection يعني عندك 2000 اتصال مع PostgreSQL حتى لو أغلبهم Idle، بيضلوا حاجزين موارد من السيرفر. النتيجة؟ استهلاك RAM عالي ضغط على PostgreSQL بطء بالاستعلامات احتمال توصل لحد max_connections النظام يصير يرفض اتصالات جديدة لهيك لازم تستخدم Connection Pooler مثل pgBouncer. فكرته بسيطة: بدل ما كل طلب يفتح Connection مباشر مع PostgreSQL، pgBouncer بيقف بالنص، ويدير عدد قليل وفعال من الاتصالات الحقيقية. يعني التطبيق ممكن يرسل عدد كبير من الطلبات، لكن قاعدة البيانات ما تنضغط بعدد اتصالات ضخم. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

اكتر شي رح يواجهك مع PostgreSQL هو الـ Query البطيئة اللي ما بتعرف سببها ليش؟ اكبر غلط ممكن توقع فيه هو انك تحاول تحزر او تخمن شو السبب فممكن يخطر عبالك: • يمكن المشكلة بالـ index • يمكن الجدول كبير • يمكن الـ join غلط !! بس الحلو انه بدال كل هالتخمين هاد فيك بكل بساطة تستخدم:

EXPLAIN (ANALYZE, BUFFERS)

لانه بشغلك الاستعلام و بيعطيك معلومات واضحة مثل: كم أخذ وقت حقيقي هل استخدم Index أو عمل Sequential Scan أي جزء من الاستعلام هو الأبطأ كم قرأ من الذاكرة RAM كم اضطر يقرأ من الهارد هل المشكلة بالـ Join، Sorting، Filtering، أو غيرها ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

بما انه شعبية PostgreSQL عم تكبر كل يوم اكتر رح نززلكم سلسلة منشورات بتحكي عن أشهر الأخطاء اللي ممكن تواجهك معها و نصائح مهمة كتير تتبعها لما مشروعك رح يصير Production ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال