muninで使われてるRRDtoolsとかは4GB rolloverを考慮した作りになってる

@unarist サイズ的にはこんなです https://gist.github.com/tateisu/1560973774265a5be6d5d5c0c7fdc2d8

@unarist ウチだとこんなでした https://gist.github.com/tateisu/a8e1d018064e15b984909064f1716402

https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1 FTLでは部分インデックスが使われなかったのでLTL専用のインデックスに書き直しました

じゃあさっきのgist記事を更新しときますか…

このアカウントは、notestockで公開設定になっていません。

LTLが過疎りがちなおひとり様タンスだとLTL専用に部分インデックス作った方がいいんだろうなあ… FTLの方は別に最適化いらないだろうと思わなくもない

ほんとはLTLとFTL個別に部分インデックス作った方が速いけど、容量との兼ね合いもあるしどうなんだろ。FTLのクエリでさっきの部分インデックスが使われるのかどうか確認してない

らずぱいゼロとカメラモジュールかな。らずぱい割と普通のLinuxで楽しいよね

このインデックス入れるとLTLが過疎ってる場合のAPI応答性が大幅に改善しますが、インデックスを増やすことによるコスト増加と見合うかどうかは人によると思います。
https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1

というわけでLTL,FTLのクエリ負荷を軽くするインデックス。

CREATE INDEX accounts_not_silenced ON accounts using btree
(id)
WHERE not silenced;

CREATE INDEX statuses_public ON statuses using btree
(id,("statuses"."local" = TRUE OR "statuses"."uri" IS NULL))
WHERE "statuses"."visibility" = 0
AND (statuses.reblog_of_id IS NULL)
AND (statuses.reply = FALSE OR statuses.in_reply_to_account_id = statuses.account_id) ;

https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1 部分インデックスを貼ると8msのクエリが1.5msになった

ああ、このケースだとaccounts.silences 見てるから結局アカウントテーブルにもアクセスが必要になるのか… cost見ると別に減ってないしなあ…

@zundan 時報か天気ボットでも入れてLTLを微妙に賑やかすと一発で解決するんでは。

あとaccounts へのjoinをin(select...) に置き換えると実行時間が44%下がります。
https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1