あっそうかDMLはEXPLAINしてボトルネック一発でわかるとかできないわけね(日頃問い合わせのパフォーマンスしか考えないからDML側が重いときのことって考えたことなかった)
“部分インデックスが使用されるためにはその定義に含まれるWHERE句の条件(この場合deleted_at IS NULL)が問い合わせの条件に包含される必要があります。また、他にインデックスはありましたがuser_idを先頭に指定しないイン
業務パッケージやアドオンだと不整合防ぐためにこういうのはDELETE前に各テーブルに存在チェックしてアラートだすロジック入れてること多いんであんま出くわさないが、確かにこれ遭遇したらハマりそうだなあ。
ほへー。deleteは禁書扱いなので論理削除やパーティションで区切ったりテーブルそのものをdrop/truncateしたりしてた
"オチ:結局はインデックス" 初手でSELECT文に変えてのEXPLAIN ANALYZEしつつ、DELETE文特有のトリガー等にも気をつけよう、ということか
こういうの解決すんのめっちゃ気持ちええよな
このレベルは全然分からん
結局インデックスやんけ...
90秒かかるDELETE文の原因を探る【PostgreSQL】 - エムスリーテックブログ
あっそうかDMLはEXPLAINしてボトルネック一発でわかるとかできないわけね(日頃問い合わせのパフォーマンスしか考えないからDML側が重いときのことって考えたことなかった)
“部分インデックスが使用されるためにはその定義に含まれるWHERE句の条件(この場合deleted_at IS NULL)が問い合わせの条件に包含される必要があります。また、他にインデックスはありましたがuser_idを先頭に指定しないイン
業務パッケージやアドオンだと不整合防ぐためにこういうのはDELETE前に各テーブルに存在チェックしてアラートだすロジック入れてること多いんであんま出くわさないが、確かにこれ遭遇したらハマりそうだなあ。
ほへー。deleteは禁書扱いなので論理削除やパーティションで区切ったりテーブルそのものをdrop/truncateしたりしてた
"オチ:結局はインデックス" 初手でSELECT文に変えてのEXPLAIN ANALYZEしつつ、DELETE文特有のトリガー等にも気をつけよう、ということか
こういうの解決すんのめっちゃ気持ちええよな
このレベルは全然分からん
結局インデックスやんけ...