みなさんこんにちは、
「推定読了時間」で「上位 X 件」のトピックをリストアップするデータエクスプローラーのクエリを作成することは可能でしょうか？
Discourse 上で、読むのに最も時間がかかるトピックが知りたいのです 
（余談ですが、@simon さんのこの投稿に続き、なぜかこの投稿に data-explorer タグを追加できないようです）
あのトピックで提案したアプローチは改善が必要だと思います。一つの問題は、メタで投稿にタグ付けできるのが TL3 以上のユーザーに限られていることです。つまり、サイトの大多数のユーザーは私の指示に従うことができません。もう一つの問題は、回答がないトピックと回答済みのトピックの両方に data-explorer タグが付いてしまうことです。これではクエリの検索にはあまり役立ちません。
遅くなって申し訳ありません。サイトのデータエクスプローラークエリをどう整理するかという質問に忙殺されていました。data-explorer タグを使うのが理想的な解決策だとは思いますが、データエクスプローラークエリを含むトピックには、TL3 権限を持つユーザーがタグを付与する必要があります。
以下のようなクエリで、お探しの情報が得られると思います。
SELECT
topic_id,
category_id,
SUM(total_msecs_viewed) / 60000 AS estimated_minutes_read
FROM topic_users tu
JOIN topics t ON t.id = tu.topic_id
WHERE t.deleted_at IS NULL
AND t.archetype = 'regular'
GROUP BY tu.topic_id, category_id
ORDER BY estimated_minutes_read DESC
LIMIT 100
クエリの最後の行にある LIMIT 100 は、より多くの結果を取得したい場合に調整または削除できます。
興味深いことに、Meta で記録された読了時間が最も多いトピックは Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) です。現在、その時間は 126048 分となっています。
こんにちは、@simon さん
その数式は正しいですか？
ランダムに 4〜5 件選んで、このクエリでの「推定読了時間」カラムの結果と、トピック自体にある「推定読了時間」を比較すると、数字が大きく異なります。
そのクエリは、最も長い時間読まれたトピックを表示するものであって、読むのに最も時間がかかるトピックを表示するものではないでしょうか？
あ、それなら問題の原因が説明できそうですね。
おそらく total_msecs_viewed はここで使うべき列ではないのでしょうか？
ユーザーがトピックを読むのに要する平均時間を使用できます。
その場合、SUM 関数を AVG に変更するだけで、次のようになります。
SELECT
topic_id,
category_id,
AVG(total_msecs_viewed) / 60000 AS estimated_minutes_read
FROM topic_users tu
JOIN topics t ON t.id = tu.topic_id
WHERE t.deleted_at IS NULL
AND t.archetype = 'regular'
GROUP BY tu.topic_id, category_id
ORDER BY estimated_minutes_read DESC
LIMIT 100
ご提案ありがとうございます、@michebs さん。しかし、残念ながらこれも大きく的外れです。
いくつかの例を挙げます：
| クエリの内容 | トピックの内容 |
|---|---|
| 438 | 61 |
| 353 | 58 |
| 335 | 40 |
| 196 | 24 |
でも、それだと平均して1人がそのトピックを読むのに438分かかることになりますよね？それはあまり現実的ではないように思えます。少しばかげた質問かもしれませんが、60,000の桁数（0の個数）は合っていましたか？
追記: もしかして、AVG（平均）にはトピックの再読も含まれているのでしょうか？つまり、1回通して読むだけで61分ですが、実際にはユーザーは平均して438分そこに滞在している、と。
ただ、今となってはサマリーの「推定読了時間」がどのように計算されているのか非常に気になってきました。理想的にはそれらが一致するはずです。10分の1に縮小しても、せいぜい概算の範囲に収まる程度でしょう。
はい、その通りです 
少し検索してみたら、こちらが見つかりました："There are 84 replies with an estimated read time of 0 minutes." - #9 by nbianca
これらの仕組みを解読するのは苦手ですが、どうやら単語数に時間を掛けた計算式（画像など単語のない投稿をカバーするための最小時間も含む）を使っているようです。
最終的な値の名称の手がかりとなるものも見つかりました：\u003csmall\u003e（ただし古い情報なので、変更されているかもしれません）\u003c/small\u003e
あまり参考にならないかもしれませんが、念のため共有しました。
あなたが探している答えが見つかることを願っています。
もう一度確認しましたが、これは（最も簡単な形式では）topic.word_countに「読書時間単語数」管理設定（デフォルトは500単語/分）を掛けたもののように思われます。したがって、このクエリは「最も読書時間の長い」トピックのトップXを生成すると思います。
-- [params]
-- integer :limit = 10
SELECT t.id as topic_id, (t.word_count)/500+1 AS estimated_read_time
FROM topics t
WHERE t.word_count IS NOT NULL
AND t.archetype = 'regular'
ORDER BY t.word_count DESC
LIMIT :limit
ただし、「写真トピックで単語数がない場合」を考慮するための「4秒ミニマム」という代替案もあります。（投稿数 x 4）/60。これは両方で機能し、大きい方が表示されます。しかし、それをどのように追加するかはまだ完全には把握できていません。
残念ながら、十分にテストできるほどの規模のサイトがないため、微調整が必要になるかもしれませんが、小さなテストサンプルでは機能したようです。
編集: OPの仕様に近づけるために「limit」パラメータを追加しました。
よし、うまくいったようだ！
@JammyDodger 君のクエリを実行したよ。参考までにスクリーンショットをいくつか貼っておくね。
まず、「トップ10」だよ。
そして、案の定：
いくつか数字が完全に一致しないところもあるけど、本当に近いよ！
写真を追加する方法を必ず見つけ出す必要があります。 まだ諦めていません。
もう一度試してみました。 100%確信はありません。テスト対象となる十分なサンプルがないためですが、テストトピックは検出されました。
-- [params]
-- integer :limit = 10
WITH read_time AS (
SELECT t.id as topic_id,
(t.word_count)/500+1 as word_count_time,
(t.posts_count*4)/60+1 as post_count_time
FROM topics t
WHERE t.word_count IS NOT NULL
AND t.archetype = 'regular'
AND t.deleted_at IS NULL
)
SELECT topic_id, CONCAT (CASE WHEN word_count_time > post_count_time THEN word_count_time ELSE post_count_time END, ' min') AS estimated_reading_time
FROM read_time
ORDER BY estimated_reading_time DESC
LIMIT :limit