الموضوع. إعادة تعيين جميع أعلى النقاط يستهلك كل مساحة القرص المتاحة

أثناء العمل على حاوية محلية قمت فيها باستيراد بيانات من منتدى SMF2 يحتوي على 20 عامًا من النشاط، واجهت خطأً يوقف العمل مع Topic.reset_all_highest.
بعد استيراد البيانات، تُظهر قاعدة بياناتي حوالي 60 ألف موضوع عادي وحوالي 400 ألف موضوع رسائل خاصة، وتتسبب الاستعلامات في Topic.reset_all_highest في نوع من النمو الهندسي للصفوف، مما يؤدي إلى نفاد مساحة القرص لدي (مع وجود 120 جيجابايت مجانية في البداية).
أحاول حاليًا تقسيم الاستعلامات إلى أجزاء يمكن إدارتها وتشغيلها مباشرة في Postgres، ولكن هذا بالطبع دون المستوى الأمثل (ولست متأكدًا مما إذا كان يعمل وينتهي به الأمر بنتائج صحيحة).
حاولت معرفة ما إذا كان أي شخص آخر قد واجه هذا النوع من المشاكل ولكني لم أجد شيئًا، لذلك أتساءل عما إذا كان هذا قد يكون مرتبطًا بإعداداتي الخاصة - أنا أستخدم أحدث إصدار من Docker، للعلم.

إعجاب واحد (1)

لقد أجريت استيرادًا متوسط الحجم مؤخرًا ولا يزال عالقًا إلى أجل غير مسمى على Topic.reset_all_highest واضطررت إلى إنهاء الاستعلام في Postgres للمتابعة. لم أواجه هذه المشكلة من قبل واعتقدت ربما أن خادم Postgres الخاص بي كان محملاً بشكل زائد (يحتوي على عدد من المواقع المتصلة).

خطوتي التالية كانت الانتقال إلى خادم Postgres آخر، لكنني لم أقم بذلك بعد.

بعد أن سارت أول جزئين من تجربتي “الاستعلام المقسم” بسلاسة (X و Y للمواضيع العامة)، جربتها مع Z، وتجمدت - أي أن الاستعلام كان نشطًا وفقًا لنشاط postgres، وأظهر top العملية قيد التشغيل بنسبة 100%.
لذلك نظرت مرة أخرى إلى SQL ووجدت المشكلة: كلا الاستعلامين ينتهيان هكذا

      WHERE
        topics.archetype <> 'private_message' AND
        X.topic_id = topics.id AND
        Y.topic_id = topics.id AND
          (
          topics.highest_staff_post_number <> X.highest_post_number OR
          topics.highest_post_number <> Y.highest_post_number OR
          topics.last_posted_at <> Y.last_posted_at OR
          topics.posts_count <> Y.posts_count OR
          topics.word_count <> Z.word_count
        )

(الآخر لديه ‘private_message’ كنمط، بالطبع)
مما يعني أن الاستعلام يفتقد
Z.topic_id = topics.id - مما يسبب الزيادة الهندسية بأكملها.

تغيير عبارة WHERE للاستعلامات إلى

      WHERE
        topics.archetype <> 'private_message' AND
        X.topic_id = topics.id AND
        Y.topic_id = topics.id AND
        Z.topic_id = topics.id AND
          (
          topics.highest_staff_post_number <> X.highest_post_number OR
          topics.highest_post_number <> Y.highest_post_number OR
          topics.last_posted_at <> Y.last_posted_at OR
          topics.posts_count <> Y.posts_count OR
          topics.word_count <> Z.word_count
        )

أصلح المشكلة بالنسبة لي.

هل يجب أن أفتح طلب سحب؟

إعجابَين (2)

أعتقد ذلك. إذا كان بإمكانك العثور على التزام كسر ذلك، فسيكون ذلك أكثر إقناعًا.

إعجاب واحد (1)

لقد فتحت طلب سحب (PR) لهذا، مع بعض القيود المؤسفة (أي، لا يمكنني تخيل كيفية اختبار هذا التغيير).

6 إعجابات

يبدو هذا التغيير صحيحًا أيضًا، سأقوم بدمجه.

(من ناحية الاختبار، يجب أن يكون هناك تغطية واختبار بسيط سيكون كافيًا للتحقق من صحته، نحتاج فقط إلى التأكد من عدم وجود تراجع)

5 إعجابات