شكراً جاي! أقدر التشجيع.
أوه، أفضل ألا أفكر في ذلك. 
ربما استغرق الأمر أكثر من 15 أو 20 ساعة بعد أن وضعتني على المسار الصحيح باستعلام SQL.
أود أن أستفيد من خبرتك في هذا الأمر إذا كانت لديك أي أفكار:
استغرق الأمر حوالي 70 ساعة لإجراء تجربة كاملة ببيانات الإنتاج على خادم افتراضي خاص قوي جدًا. أود أن أجعل مستخدمي يتفاعلون مرة أخرى في أسرع وقت ممكن حتى لو كان استيراد المنشورات والرسائل الخاصة لا يزال غير مكتمل. أو فكرة بديلة أخرى خطرت ببالي وهي تعطيل وظيفة preprocess_posts، والتي قمت بتعديلها أيضًا بشكل كبير مع استبدالات إضافية لـ gsub للتعبيرات العادية، وكذلك لتمرير جميع المنشورات والرسائل الخاصة عبر Pandoc بأحد أوامرين مختلفين اعتمادًا على ما إذا كان المنشور الأصلي عبارة عن علامات Textile أو HTML خالصة. إذا قمت بتعطيل روتين preprocess_posts بالكامل، فقد يقلل ذلك من وقت الاستيراد إلى النصف تقريبًا، وبعد ذلك يمكنني إضافة كل تلك الأشياء المتعلقة بالتنسيق إلى قسم postprocess_posts بمجرد استيراد جميع البيانات الأولية. ولكن العيب هو أنه بعد ذلك لن أتمكن من الوصول بسهولة إلى عمود قاعدة البيانات الأصلي الذي يظهر تنسيق المصدر (Textile أو HTML) لكل منشور، وهو شرط لمعالجة Pandoc الخاصة بي. أو هل يمكنني إضافة حقل مخصص لكل منشور يصفه بأنه textile أو html ثم استعادته لاحقًا أثناء المعالجة اللاحقة؟ لا أعرف، أفكر بصوت عالٍ فقط.