AWS RDSでもDBAはparameterチューニングする - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社で某テック・リーダーの遺産として「PostgreSQL 運用管理トレーニング」が1月に実施されたのはまだ記憶に新しいところ。 あのときのリーダーの言葉、憶えているうちに書き留めておこう。 「Managed Service で RDB を使う時代になっても、この研修で扱う知識はDBAもApplication Engineerも持っておくべきだと信じて、企画し実現しました」 （この記憶はほんとうか？ 意訳や美化が入っているかもしれない） 事例の1つを共有しましょう。 担当プロダクトの背景事情 担当プロダクトで使っているPostgreSQ
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
ad3e04e50357a1e758fc#_reference-a1b4100c3771c36dfbe6
SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
