PostgreSQLアンチパターン：外部キー制約の更新コストを見くびる - Qiita

このTABLE定義であやういところはどこでしょう？ サービスにどんなインシデントが発生したか想像できるでしょうか？ CREATE TABLE reports ( id bigserial NOT NULL, user_id bigint NOT NULL, time_of_report timestamp without time zone NOT NULL, previous_report_id bigint REFERENCES reports (id), elapsed_time integer NOT NULL DEFAULT 0, CONSTRAINT reports_id_pkey PRIMARY KEY(id), CONSTRAINT reports_user_id_fkey FOREIGN KEY(user_id) REFERENCES users(id) MATCH SI

[n314]

なんで外部キー制約に標準でインデックス付かないんだと思っている。外部キー制約って名前の通り制約なんだけど、キーって単語もあるから何かインデックスっぽいものがあると思ってしまう。

[tmatsuu]

外部キー制約の更新コスト、EXPLAIN ANALYZEで検出できるんだろうか。気になるな

[vanbraam]

"実は previous_report_id は定義されたものの、使ってなくて、500万行全てで NULL だった"<こっちの方が遥かに"アンチパターン"だと思うが.というか論外では

[koyancya]

まって、previous_report_id って...

[te2u]

外部キー制約がつけられるカラムはその性質上、検索、更新などの軸となるカラムなので、制約をつける段階でインデックスをつけることを検討するようにしている。/ORMを使っていると、この辺りは自動生成される。