Notices by おさむ (samunohito@mi.osamu-storage.info)

{ "day": "13", "dayOfWeek": "Friday" }

内閣官房情報通信技術総合戦略室も推奨するここすき
https://github.com/misskey-dev/misskey/issues/4947

ダーッと書けますよって

RE: https://uneune.one/notes/a0n56axu4j

なるほど、どちらも単位が「柱」・・・
神と人柱をかけた高度な

[穴, 穴, 穴, 穴, 穴, 穴]

＿人人人人人人＿
＞　穴リスト　＜
￣Y^Y^Y^Y^Y^Y^￣

firebaseしんどい（n回目）

「多少は改善された」くらいな気がしている…本当に解消するなら、バックグラウンドに移動したら全WebSocketを止めるくらいしないとダメな気がしてて

ずっと精神の隅っこで燻ってたタスクを倒した:neko_patari_nya:

やあ （´・ω・｀)

ようこそ、バーボンハウスへ。

このテキーラはサービスだから、まず飲んで落ち着いて欲しい。

うん、「また」なんだ。済まない。

仏の顔もって言うしね、謝って許してもらおうとも思っていない。

でも、この項目を見たとき、君は、きっと言葉では言い表せない「ときめき」みたいなものを感じてくれたと思う。

殺伐とした世の中で、そういう気持ちを忘れないで欲しい

そう思って、この項目を作ったんだ。

じゃあ、注文を聞こうか。

もうFirebase/GCP触りたくねえ

@fruitriin@misskey.systems わかる（現在進行形で苦しんでる）

ものすごく勝手なことを言うが、以前提供してもらったdumpで検証して効果がありそうならみすてむフォークにprして実験台になってもらうか（）

@fruitriin@misskey.systems ごめん、ドキュメントをチラ見しただけで衝動的にリプしたけど改めてみると大して変わらんかもしれん

https://www.postgresql.jp/document/8.4/html/indexes-ordering.html

@fruitriin@misskey.systems create indexのときにnulls firstとかやったら変わったりするかしら

@fruitriin@misskey.systems 木構造でnullは使えん→あ～ってなった。ぽすぐれ側が何とか効くようにしてくれてて、その範囲を逸脱する用法だからちゃんと対策が必要という認識になった

@fruitriin@misskey.systems かしこくなった

@fruitriin@misskey.systems b-treeの性質をちゃっぴーに教えてもらったんだけど、「木構造として探索不可能（≒b-tree構築不可能）なnullな値が紛れ込む型」だとレコード数が増えてきたときにオプティマイザが「これindex使えんわ、フルスキャンしたろ」ってなりやすいらしい。なのでIS NULLで検索するとフルスキャンになる。

非nullな値で検索するときはnullの値を無視するのでこの問題が起きないらしい…nullableをやめてbooleanのカラム生やしたら改善する可能性がある

「IS NULLが混在すると性能が劣化する」がなぜそうなのかを探る必要があるな…

膨大なレコードを持つテーブルのマイグレーションを伴うアップデートを実装する前に、不要レコードを消せるお掃除機能を用意する必要があると感じているが、

@fruitriin@misskey.systems host IS NULLをやめてisRemoteなりisLocalなりbooleanのフラグを生やした方が早くなる？