PostgreSQL 17からEXPLAINにSERIALIZEオプションが追加され、クエリをシリアライズするコストも取得できるようになりました | DevelopersIO
EXPLAIN (ANALYZE)の弱点を克服 PostgreSQLではEXPLAINコマンドで実行計画を取得できます。特に、ANALYZE オプションを追加すると、実際にクエリを発行して実行計画と実行処理時間の両方を取得できます。 ただし、このANALYZEオプションにも欠点があります。 PostgreSQLでは2kBを超える *1データをテーブルに格納する際には、TOAST(The Oversized-Attribute Storage Technique)化され、特殊領域にデータ配置されます。 クエリ実行時にシリアライズを伴うようなケースにおいて、シリアライズ処理も含めた処理時間やシリアライズ後のワイアフォーマットでのデータサイズは、実際にクエリを実行しないと取得できませんでした。 EXPLAIN (ANALYZE, SERIALIZE) というように SERIALIZE オプション
PostgreSQLの実行計画の推定行数と実行数の乖離改善の考え方
はじめに 以前こんなツイートをしました。 すると、リプライで色々とコメントを頂きました。（疑問を投げかけたら答えてくれる方々、本当にいつもありがたいです🙇♂️） ということで、本記事では推定行数と実際の行数の乖離を減らすために何をやったのかを備忘として書きます。 ただ、実際のSQLや実行計画を書くことはできないので、あくまでどんな考え方をしたのか、ということを書きます。 対処法①（対象のテーブルのautovacuum頻度を変更） 対象のテーブルはかなり更新の激しいテーブルだと聞いていたので、まずは統計情報が最新化されているかを考えました。 更新が激しくてautovacuum時の自動ANALYZEが追い付いていないんじゃないかと考え、対象のテーブルだけ自動ANALYZEの頻度が上がるように設定を変更しました。 PostgreSQLの設定パラメータは基本的にはpostgresql.conf
型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
PostgreSQLのロール・権限のここがわかりづらい
App Router への移行は「改善」となり得るのか？/ Can migration to App Router be an improvement
PostgreSQLをストリーミングレプリケーションで構成する (PostgreSQL 10.x版)
事前作業として、検証目的なので、firewalldとSELinuxは無効化しておこう。 [Master/Standby]# systemctl stop firewalld [Master/Standby]# systemctl disable firewalld [Master/Standby]# sed -ie 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config [Master/Standby]# reboot ストリーミングレプリケーション構成手順概要 PostgreSQLでストリーミングレプリケーションを構成する手順の概要を以下に図示する。 ①PostgreSQLインストール・初期セットアップ 1. dnfでPostgreSQLをインストール まずは、PostgreSQLをインストールする。postgresql-
PostgreSQLで多数のパーティションを持つテーブルに対してPrepared Statementを実行した際の性能劣化について調べてみた | DevelopersIO
※実行時間の単位は全てmsです パーティション数が1,000になると汎用プランの再検証で1000パーティションへのスキャンが発生するため、bindが遅くなっていることが分かります。気になっていたunnamedなPrepared Statementについては名前付きのPrepared Statementに比べて早いような気もするし、誤差のような気もするし...ここはもう少し計測回数を増やして詳しく見ていきたいところです。 WHERE句をリテラルで記述した非Prepared Statementの場合は1000パーティションかつforce_generic_planの場合でも6.2msで処理できており、汎用プラン再検証のオーバーヘッドが発生していないことが伺えます。 1000パーティションのテーブルに対して1000回クエリを発行してbindのオーバーヘッドを確認してみる 先程の検証結果から 100
検索が爆速になるデータベース設計を公開します
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
MySQL/Postgres におけるトランザクション分離レベル
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する https://zenn.dev/mpyw/articles/rdb-transaction-isolations 上記のスライドの具体的な結論に至るまでの導入として，知識があまりない状態でも段階的に読み込んでいけるように心がけたスライドで，株式会社ゆめみの社内勉強会にて発表しました。 スライドの途中の URL などは PDF としてダウンロードするとクリックできると思います。 事前のレビュー協力者 - https://twitter.com/neko_han25 - https://twitter.com/KentarouTakeda
最速でVacuumを完了させる方法とその副作用
Vacuumはなぜ時間がかかる？ そのテーブル本当に必要ですか？ テーブル構造を変える パラメータを調整する INDEX_CLEANUP offの副作用 まとめ これはPostgreSQL Advavent Calendar 2022の21日目のエントリです。昨日は、@tom-satoさんによるPostgreSQL でページの中身を視覚的に表示してみるでした。 通常Vacuumはautovacuumによってテーブルの削除済みの行数や、新しく追加された行数をベースに自動的に実行されます。autovacuumによって行われるVacuumで問題なくテーブルのメンテナンスが行われる状況が理想的ではありますが、特にXID周回問題が絡んでくると、Vacuumを実行にできるだけ早く完了させたくなることがよくあります。 XID周回問題についてはネット上に色々な解説があるのでここでは詳しく説明しませんが、端
あまり知られていないPostgreSQLの機能 | POSTD
あなたが知らない既存機能があるかもしれません！ マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre
PostgreSQLエンジンでのAuroraとRDSのベンチマーク - so what
PostgreSQLエンジンでAuroraとRDSでpgbenchを使った負荷テストを行った。 テスト環境 クライアント pgbench (PostgreSQL) 14.2 (Ubuntu 14.2-1ubuntu1) EC2のc5.2xlargeインスタンスから実行 クライアントインスタンスの性能上限には引っかかっていないことは確認 以下のようなスクリプトを実行 スケールファクター: 100 トランザクションタイプ: デフォルト（TPC-B like） #!/bin/bash . .rds for i in 8 16 32 48 64; do echo "--- $(date +%FT%TZ) RDS $i" pgbench -i -s 100 -q pgbench -c $i -T 210 sleep 60 done echo "--- $(date +%FT%TZ) RDS end"
メルペイDataPlatformのCDC DataPipeline | メルカリエンジニアリング
こんにちは、メルペイ DataPlatformチーム(@rerorero, @darklore, @laughingman7743)です。 この記事は、Merpay Tech Openness Month 2022 の14日目の記事です。 今日はメルペイ DataPlatformで取り組んでいるCDCパイプラインについて紹介します。 CDCパイプラインとは何か CDCとは Change Data Capture の略称で、データベース内のデータの変更（新規作成、削除、変更など）を追跡するシステムです。データソースで発生した変更は、ニアリアルタイムでデータシンクに反映させることができます。 CDCの実現方法にはいくつかあるのですが、メルペイ DataPlatformでは以下の2つの方法を使ったパイプラインを構築しています。 Striim社のブログ がよくまとまっていたので、こちらから引用させ
PostgreSQL のプリペアド文で汎用的な実行計画を選択するタイミング - ぱと隊長日誌
PostgreSQL ではプリペアド文を繰り返し実行していると、汎用的な実行計画を作成することがあります。これにより、実行計画作成のオーバーヘッドを回避できます。 「汎用的な実行計画」と「独自の実行計画」のいずれを使うのかはマニュアルで説明されています。 デフォルト(すなわち、plan_cache_modeがautoに設定されている場合)では、パラメータのあるプリペアド文に対して、汎用的な計画を使うか独自の計画を使うかを、サーバは自動的に選択します。 これに対する現在の規則は、最初の5回が独自の計画で実行され、その計画の推定コストの平均が計算される、というものです。 それから汎用的な計画が作成され、その推定コストが独自の計画のコストの平均と比較されます。 そのコストが独自の計画のコストの平均よりもそれほど高くなければ、再計画を繰り返すことが望ましいと考えて、その後の実行は汎用的な計画を使い
PostgreSQL の auto_explain のパフォーマンスへの影響 - ぱと隊長日誌
概要 PostgreSQL の auto_explain モジュールはスロークエリの実行計画をログ出力する手段を提供します。このモジュールを有効化することでパフォーマンスにどの程度影響を与えるのか、PostgreSQL に同梱されている pgbench で検証を行いました。 対象バージョン 検証には PostgreSQL 14.1 を用いました。 ただし、日本語ドキュメントは現時点の最新である 13.1 を参照しています。 事前調査 マニュアル auto_explain のマニュアルでパフォーマンスに関して特に目を引くのが以下の2点でした。 より一般的な使用方法は、postgresql.confのsession_preload_librariesまたはshared_preload_librariesにauto_explainを含めて、特定のまたはすべてのセッションで事前にロードしておくこと
OID 別名型を使って PostgreSQL の内部情報を取り出す - Qiita
こちらは PostgreSQL Advent Calendar 2021 の 21 日目の記事です。 今回は、PostgreSQL の内部情報を調べるときに役立つ、regclass や regnamespace などの OID 別名型 を紹介します。 PostgreSQL では、テーブルやスキーマなど、すべてのオブジェクトには OID と呼ばれる識別子が割り振られていて、システムカタログと呼ばれる内部情報が入ったテーブルでは、この OID が至るところに出てきます。 例えば、システムカタログ pg_class にはテーブルやインデックスなど、リレーションの情報が入っています。 =# SELECT oid, relname, relnamespace, relowner FROM pg_class; oid | relname | relnamespace | relowner ------
PUBLICロールにREVOKEってるやついる？ - Qiita
（ネタとしてはもう古い・・・） 本記事はPostgreSQL AdventCalenderの16日目の記事です。 はじめに 本記事はPostgreSQL 15develを対象に確認した結果を使用しています。開発中のものであるため、リリース時には挙動が変わっている可能性がある点にご注意ください。 元々はROLEの設計について書こうと思っていたのですが、定義済みロールに見かけない子（pg_database_owner）がいたので気になって調べていたら、皆様ご存知のPUBLICロールへのREVOKEがPostgreSQL 15からは不要になるという話があったので確認してみたという話になります。 （割とインパクトのある変更なので、既にご存知の方も多いかもですが汗。） 環境 CentOS 7 PostgreSQL 14.1 15devel（2021/12/8時点） 定義済みロール（Predifine
AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証 | Amazon Web Services
Amazon Web Services ブログ AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証 データベースの移行は複雑なタスクになりかねません。移行には、ソフトウェアプラットフォームの変更、ソースデータの複雑性の把握、データ損失チェック、既存機能の詳細なテスト、アプリケーションパフォーマンスの比較、およびデータの検証といったあらゆる課題が伴います。 AWS では、移行前チェックリストと移行評価を提供するツールとサービスをいくつかご用意しています。AWS Schema Conversion Tool (AWS SCT) は、既存のデータベーススキーマをひとつのデータベースエンジンから別のデータベースエンジンに変換するために使用できます。AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、
PostgreSQLで排他制約がめっちゃ便利！！ - そーだいなるらくがき帳
中国地方DB勉強会っていう控えめに言っても最高の勉強会があるんだけどそこで排他制約について教えてもらいました。 ikkitang1211.hatenablog.jp 排他制約って雑に説明すると重なりを拒否する制約です。 僕は使った事なかったのですが勉強会の中で事例紹介を受けて、めっちゃ便利だったのでここでご紹介します。 どんなときに使うの？ 実際にはどんなときに重なりを制御したいかというとよく使うのは次の2つ。 図面の重なり 時間の重なり 1つ目は幾何学的な図面を表現するときです。 実際にPostgreSQLは円や四角をSQLで表現できます。例えば地図上で特定の座標から半径100メートルの円を書き、その中に特定の円(場所)があればErrorにするような制約が書けます。 そもそもSQLで位置計算もめっちゃ便利なので是非使ってみてください。 soudai1025.blogspot.jp そして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLのDBを手動フェイルオーバーする手順 (ストリーミングレプリケーション構成)
pg_hint_planを知る（第37回PostgreSQLアンカンファレンス@オンライン 発表資料）
