제이, 고마워! 격려해 줘서 정말 고마워.
아, 그건 생각하기 싫은데. 
SQL 쿼리로 올바른 방향을 잡아준 덕분에 아마도 15시간에서 20시간 이상은 걸렸을 것 같아.
이 부분에 대해 네가 어떤 생각이 있다면 내 머리를 좀 빌려줄 수 있을까:
매우 강력한 VPS에서 프로덕션 데이터를 사용해 완전한 시험 주행을 하는데 약 70시간이 걸렸어. 게시글과 PM(개인 메시지) 가져오기가 아직 완료되지 않았더라도, 사용자들의 상호작용을 가능한 한 빨리 다시 시작하고 싶어. 또 다른 대안으로 생각한 아이디어는 preprocess_posts 함수를 비활성화하는 거야. 이 함수는 추가적인 gsub 정규식 치환을 통해 내가 상당히 수정했고, 또한 원본 게시글이 Textile 마크업인지 순수 HTML인지에 따라 두 가지 다른 명령어 중 하나로 모든 게시글과 PM을 Pandoc을 통해 처리하도록 설정했거든. 만약 preprocess_posts 루틴 전체를 비활성화하면 가져오기 시간이 거의 절반으로 줄어들 것 같고, 그러면 모든 원시 데이터가 가져와진 후에 포맷팅 관련 작업을 postprocess_posts 섹션에 추가할 수 있을 거야. 하지만 단점은 나중에 각 게시글의 원본 데이터베이스 컬럼(원본 포맷, 즉 Textile 또는 HTML)에 쉽게 접근할 수 없다는 거야. 이건 내 Pandoc 조작의 조건부 로직이니까. 아니면 각 게시글에 textile 또는 html로 라벨을 붙이는 커스텀 필드를 추가해서 나중에 후처리 단계에서 그 값을 가져올 수 있을까? 모르겠어, 그냥 소리 내어 생각해보는 중이야.