Danke Jay! Ich schätze die Ermutigung.
Ugh, das möchte ich lieber nicht bedenken. 
Es waren wahrscheinlich über 15 oder 20 Stunden, nachdem Sie mich mit der SQL-Abfrage auf den richtigen Weg gebracht hatten.
Ich würde gerne Ihre Meinung dazu hören, wenn Sie welche haben:
Es dauerte ungefähr 70 Stunden, um einen vollständigen Testlauf mit Produktionsdaten auf einem sehr leistungsstarken VPS durchzuführen. Ich möchte, dass meine Benutzer so schnell wie möglich wieder interagieren, auch wenn der Import von Beiträgen und privaten Nachrichten noch unvollständig ist. Oder eine andere alternative Idee, über die ich nachgedacht habe, wäre, die Funktion preprocess_posts zu deaktivieren, die ich ebenfalls stark mit zusätzlichen gsub-RegExp-Ersetzungen modifiziert habe und um alle Beiträge und privaten Nachrichten durch Pandoc zu leiten, mit einem von zwei verschiedenen Befehlen, je nachdem, ob der ursprüngliche Beitrag Textil-Markup oder reines HTML war. Wenn ich die gesamte preprocess_posts-Routine deaktiviere, würde dies die Importzeit wahrscheinlich fast halbieren, und dann könnte ich all diese Formatierungsarbeiten in den Abschnitt postprocess_posts aufnehmen, sobald alle Rohdaten importiert sind. Der Nachteil ist jedoch, dass ich später nicht mehr einfach auf die ursprüngliche Datenbankspalte zugreifen könnte, die das Quellformat (Textile oder HTML) für jeden Beitrag anzeigt, was eine Bedingung für meine Pandoc-Manipulation ist. Oder könnte ich jedem Beitrag ein benutzerdefiniertes Feld hinzufügen, das ihn als textile oder html kennzeichnet und diesen dann später während der Nachbearbeitung abruft? Keine Ahnung, ich denke nur laut nach.