PostgreSQL は "soft edge" があるときに、ロック取得順序を入れ替えてデッドロックの解消を試みます。

pg_hba.conf の設定は接続を試みるタイミングで検査されます。確立済みの接続には影響しません。

PostgreSQL 内部で effective_cache_size をどのように活用しているのか（もしくは活用していないのか）を確認します。

PostgreSQL の ANALYZE は pg_class 更新でトランザクション・セマンティクスに従いません。今回の記事ではこれを実験で検証します。

PostgreSQL インデックス肥大化によるインデックスコストへの影響をモデル化しました。また、実装の調査も行っています。

VS Code + GDB でリモートデバッグする手順について PostgreSQL を題材に解説します。

PostgreSQL の configure オプションを変更して再ビルドする際には make distclean を実行すべきです。

Windows 10 の Hyper-V でベンチマークを測定していると、複数 CPU 動作時に大きく性能劣化しました。これは「ルートスケジューラ」に原因があるのかもしれません。

SQL の COUNT(*) と COUNT(1) は同じ結果が得られます。また、COUNT() 内の定数が何であっても結果は同じです。

PostgreSQL の pg_stat_activity ビューで待機イベントの情報を収集すると、ボトルネック調査に役立つかもしれません。

PostgreSQL の結合テーブル数と計画時間の関係を調べました。計画時間は join_collapse_limit, geqo_threshold といったパラメータの影響を受けることが分かりました。

PostgreSQL の join_collapse_limit がプランナに与える影響を実験から推測しました。平坦化の概念をつかむことができます。

PostgreSQL のデッドロック検出待機時間パラメータである deadlock_timeout の見直しに、どれほどの優先度で取組むべきなのかを、デッドロック検出処理の仕組みの観点から調査しました。

OSS-DB Gold Ver.2.0 を合格することができました。教材・勉強方法・振り返りなどをまとめました。

「PostgreSQL 高度技術者育成テキスト」内の摸擬問題集に対し、OSS-DB Gold Ver.2.0 をベースとした差分と誤記の修正をまとめました。

PostgreSQL の式インデックス（関数インデックス）もテーブルと同様に統計情報の収集対象です。よって、式インデックス作成後に ANALYZE を実行しないと、正しく活用されません。また、pg_stats ビューは式インデックスの統計情報も参照できます。

OSS-DB Silver Ver.2.0 を受験し、無事に合格することができました。今回の挑戦に向けて、どのような準備を行ったかまとめます。

PostgreSQL ではプリペアド文を繰り返し実行していると、汎用的な実行計画を作成することがあります。この実行計画の切り替えがいつ行われるのかを調べました。

DEIM2022 「近代的トランザクション処理技法」の聴講メモです。メモは口頭説明を中心にまとめています。資料を併せてご参照ください。

PostgreSQL の一時バッファの開放はセッション終了時となります。一時テーブルの削除タイミングやトランザクションの終了タイミングではありません。

PostgreSQL には統計情報の度数分布と実際の最小値・最大値が乖離した場合の影響を抑える機能があります。この機能によって実行計画の推定行数がどのように変化するかを検証しました。

PostgreSQL でも指数表記を解釈してくれます。ですが、指数表記の暗黙的キャストが意図した型になるとは限らないことに注意が必要です。

PostgreSQL のエクゼキュータによるノードの処理順はマニュアルに解説されています。この説明をかみ砕いて説明します。

PostgreSQL の auto_explain モジュールを有効化することでパフォーマンスにどの程度影響を与えるのか、検証を行いました。

本記事では PostgreSQL の EXPLAIN コマンドの TIMING パラメータのオーバーヘッドがどこから生じているかを解説します。

リレーショナルモデルは集合を扱い、行の順序を意識しないはずです。なのになぜ SELECT-INSERT の SELECT で ORDER BY できるのか…という疑問と検証を書き留めています。

オブジェクト識別子データ型と使い方を中心に解説します。最後にその実装にも踏み込んで解説をします。

PostgreSQL にはテーブルの種類として TEMPORARY と UNLOGGED があります。この2つはワークテーブルとしてしばしば使われます。シンプルな条件下では UNLOGGED より TEMPORARY のほうがパフォーマンスが良い結果となりました。

PostgreSQL の実行計画で Hash ノードはコストが 0 として計算されていますが、ハッシュ処理のコストは Hash Join ノードに含まれています。

PostgreSQL のインデックスが肥大化した状況では実行計画のコスト計算に影響することがあります。これは適切な実行計画を選択する妨げとなるかもしれません。