本記事は PostgreSQL Advent Calendar 2023 8 日目の記事です。 pg_stasinfoとは PostgreSQLカンファレンス2023にて、株式会社アシストの保田さんがpg_statsinfoについて紹介していました。 PostgreSQLサーバの利用統計情報をスナップショットとして定期的に収集・蓄積し、レポートを生成してDB設計やPostgreSQLの運用(日々の処理傾向の把握、性能劣化などの兆候や問題発生時の原因の把握等)に役立つ拡張機能です。 詳細は公式のドキュメントを参照してください。 さらに、pg_stats_reporterという別の拡張機能を導入することで、収集した情報をブラウザで確認することができます。 pg_stats_reporter pg_statsinfoが収集した情報をブラウザで確認するための拡張機能です。 導入すると、次のような画

要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある

こんにちは。並河(@namikawa)です。 新型コロナウイルスが終息していくことを祈り、弊社もリモートワーク体制に移行しておりまして、私自身もほぼ自宅で過ごしている日々です。弊社では、従前よりフルリモートワークを遂行しているメンバーが数名いますので、各人のリモートワークへの移行も割とすんなり出来たのではないかと感じています。(細かい課題意識はもちろんありますが) さて、閑話休題。 このブログでも散々話題に出ているかと思うのですが、弊社では技術や投資にまつわるデータを大量に保有しておりまして、それぞれのデータの特性や用途によって、データストアを使い分けています。 その中でも、RDB には PostgreSQL が以前より活用されていまして、今日のエントリの趣旨は、この PostgreSQL の基礎ベンチマーク数値をバージョン毎に差異があるかを確認してみた記録となります。 ベンチマークの取得

ERROR: canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed. これは字の如く、レプリケーション側でWALの反映時にコンフリクトして強制的にクエリを殺されています。 理由は下記のスライドがわかりやすいです。 PostgreSQLによるデータ分析ことはじめ from Ohyama Masanori www.slideshare.net 詳細は公式ドキュメント読むと良いです。 26.5. ホットスタンバイ 追記（2017/12/28） 俺達のヒーロー @sawada_masahiko くんが完璧に補足してくれたのでちゃんと知りたい人はこっちを見ましょう。 qiita.com なぜコンフリク

PostgreSQL on EC2 から Amazon RDS for PostgreSQL に移行した時にハマった闇 10選PostgreSQLDMSAmazonDatabaseMigrationService 移行 への 道のり 社内で初めてのAWS商用利用サービス 単一 availability zone ほぼメンテされなくなっている自社HA構成 → なんとかしたい from : PostgreSQL 9.3 on EC2 to : Amazon RDS for PostgreSQL (9.4) Multi-AZ! これを達成するために、いくつもの闇を垣間見ることになりました。 Amazon DMS の 闇 1. ソースDB PostgreSQL 9.4 or later ソース側にレプリケーションスロットの設定が必要 （つまり、そのあたりの機能を使っている）ということでここを回避す

無駄に長い前置き　これは、PostgreSQL Advent Calendar 2017の16日目の記事です。　昨日はnuko_yokohamaさんの記事でした。 PostgreSQL10では9.6で実装されたパラレルクエリが強化されており、集計・分析業務への適合性が高まっております。 また、ある程度増減するとはいえ、CPUやメモリの価格も時の流れとともにどんどん安くなっています。　数百GBくらいのデータであれば、データを全てメモリに乗せてしまって、マルチコアでパラレルクエリをぶん回してしまえば、大抵の場合はどうにかなってしまうのではないか……と、昔から考えております。　当然、数十TBやPB級は難しいでしょうし、PostgreSQLはインメモリDBでもなければ列指向型DBでもありませんので、高速に集計をすることを前提に作られたDBMSと比較すると効率は良くないでしょう。 ただ、記事執筆時点

はじめに この記事は JustSytems Advent Calendar の 7 日目です。 以前にQiita:Teamで社内向けに書いた記事を手直ししたものになります。 当社で利用しているRDBMSの多くがPostgreSQLです。ということで、この記事もPostgreSQLを対象に書いています。 この記事の対象読者 この記事の対象読者として想定しているのは、 RDBMS を利用したアプリケーション を開発しているアプリケーションエンジニア 特に、基本的なSQLは書けるが苦手意識を持っている、あるいはDB層は完全にORMに任せてしまっていてよくわからない わからないとまで言わないが、性能に関して特段に意識したことはない。 というような方です。バリバリのDBAのみなさまからはマサカリをいただきたいですがどうぞお手柔らかにお願いします。 以下、特に断りのない場合にはPostgreSQL（の

The Qiita Advent Calendar 2017 is supported by the following companies, organizations, and services.

Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre

PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ