Спасибо, Джей! Ценю твою поддержку.
Уф, я бы предпочёл не думать об этом. 
После того как ты указал мне верное направление с SQL-запросом, это, наверное, заняло от 15 до 20 часов.
Хотел бы обсудить с тобой эту тему, если у тебя есть какие-то мысли:
На полный пробный запуск с производственными данными на очень мощном VPS ушло около 70 часов. Я бы хотел, чтобы мои пользователи снова начали взаимодействовать как можно скорее, даже если импорт постов и личных сообщений ещё не завершён. Или же у меня есть другая идея: отключить функцию preprocess_posts, которую я тоже значительно доработал, добавив дополнительные замены через gsub с регулярными выражениями, а также пропустить все посты и личные сообщения через Pandoc, используя одну из двух команд в зависимости от того, был ли исходный пост размечен в Textile или это чистый HTML. Если я отключу весь цикл preprocess_posts, время импорта, вероятно, сократится почти вдвое, а затем я смогу добавить всю эту логику форматирования в секцию postprocess_posts после того, как все исходные данные будут импортированы. Но минус в том, что после этого я не смогу легко получить доступ к исходному столбцу базы данных, который показывает формат источника (Textile или HTML) для каждого поста, что является условием для моих манипуляций в Pandoc. Или же я могу добавить пользовательское поле к каждому посту, помечая его как textile или html, а затем извлекать эту информацию позже при постобработке? Не знаю, просто мысли вслух.