あとウチで目立つスロークエリは SELECT COUNT(DISTINCT "accounts"."domain") FROM "accounts"; が600-800msかかってるんだけど、対策を思いつかないし無視していいかな…

ActiveRecordでコレを書くの面倒そうだなあ…という印象だがそもそもRuby分からんので識者によるPRが望まれる

index_statuses_20180106 のDM限定版インデクスを作った場合の実行計画も追記してみたけど、ウチの環境だと負荷が低すぎて有効なのかどうか分からなかった

https://gist.github.com/tateisu/a7de7a8ff816e83ea2894e599499849d unionの左辺と右辺にもlimitを入れた場合の実行計画を追記した

create index ではサブクエリを使えないので、mentionsテーブルのDM用部分インデクスを作るにはテーブルにカラムを追加してやる必要があるな…

@valerauko actualの方は別にそうではないので。

@fn_aki それはいらなくない？ https://gist.github.com/tateisu/a7de7a8ff816e83ea2894e599499849d みるとメンションみつけてそれにあわせたステータスを探すときにstatuses_dm 使われてるから。

https://gist.github.com/tateisu/a7de7a8ff816e83ea2894e599499849d union使うやつの実行計画。20件ずつ読んでるという訳ではないのだ。。

あと実行計画みると、limit 20 がかかるのは Append してSortして Unique してまたソートした最後の部分だけなんで、ソート対象の一時データは結構な件数がある。 アプリ側でマージする方をお勧めする

「部分インデクスいらない」とまでは言い難いなー。

DMカラムにはmin_id使うようなクエリはなさそうなので、ページネーション書くの面倒そうだけど破綻はしないと思う。なお "statuses"."id" as status_id って書いてorder byの対象には名前つきの列名を指定しないとクエリできなかった

unionでやるやつexplainかけてみたら、自分あてのメンション集める部分ではstatuses_dm (DM用部分インデクス)も使われたし index_statuses_20180106 の部分インデクス版もあった方が速いだろう。ていうかウチの場合はないとunionじゃない奴の方が速い。DMとそれ以外の比率が結構激しい。ねこまんまさんが言ってるのはコレのことじゃないかと思う

index_statuses_20180106 がだいたいそうじゃん。公開範囲全部を含むだけで ＞account_id, idへのインデックスをvisibility = 3に対して

https://youtu.be/6wuLef1DolY 寒天を避けつつキューブを斬るエクササイズを録画してみた

マストドンのWebPushってVAPIDキーを.env.productionに設定しないことで機能しないようにできるとかあるんですけど、プッシュ購読APIはその状態でも200 OKを返すというね…。(レスポンス中のサーバキーが空になるから判別不可能な訳ではない)

2.4以降のタンスだけに限定するんならプッシュ通知だけに割り切った設計もできるんですけど、まだ時期尚早

@osapon 今の通知取得はネットワークアクセス要求するし場合によっては10秒に収まらないので、なんらか通知をださないとバックグラウンド動作制限にひっかかるんですよね…

Zzz…

#SubwayTooter でプッシュ購読をご利用の方で1アカウントだけ、タンスにVAPID_PUBLIC_KEYが設定されておらずタンス側でWebPushが動作していないと思われる方が存在します。

Let's encryptの有効期限の短い鍵でHPKPするのが間違いなんだろうか…

証明書の更新でPublic-Key-Pinsにささった奴です…