Merci Jay ! J’apprécie tes encouragements.
Argh, je préférerais ne pas y penser. 
C’était probablement plus de 15 ou 20 heures après que tu m’aies mis sur la bonne voie avec la requête SQL.
J’aimerais te poser quelques questions à ce sujet si tu as des idées :
Il a fallu environ 70 heures pour faire un essai complet avec des données de production sur un VPS très puissant. J’aimerais que mes utilisateurs interagissent à nouveau le plus rapidement possible, même si l’importation des posts et des messages privés est toujours incomplète. Ou une autre idée alternative à laquelle j’ai pensé serait de désactiver la fonction preprocess_posts, que j’ai également fortement modifiée avec des remplacements supplémentaires par expressions régulières gsub et aussi pour faire passer tous les posts et messages privés par Pandoc avec une ou deux commandes différentes selon que le post original était du balisage Textile ou du HTML pur. Si je désactive toute la routine preprocess_posts, cela réduirait probablement le temps d’importation de moitié, et je pourrais ensuite ajouter tout ce matériel de formatage dans la section postprocess_posts une fois que toutes les données brutes sont importées. Mais l’inconvénient est qu’après coup, je ne pourrais pas facilement accéder à la colonne de la base de données d’origine qui indique le format source (Textile ou HTML) pour chaque post, ce qui est une condition pour ma manipulation Pandoc. Ou pourrais-je ajouter un champ personnalisé à chaque post le labellisant comme textile ou html et le récupérer plus tard lors du post-traitement ? Je ne sais pas, je réfléchis à voix haute.