今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年10月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。
PostgreSQL 性能問題の調査に役立つパラメータ設定と拡張
PostgreSQLサポートでは「SELECTが突然遅くなった」「データベースが全体的に遅い時間帯がある」「バッチの実行時間が5分から2時間になった」などの問い合わせをいただきます。
その際、調査をするための情報として、現在の設定やログ、SQLが遅延した時に実行時間とSQL文をログに出すとか実行計画もあわせて出すとかをしておけば、遅延が発生した時や通常とは異なる状況の時に、通常とは何が違うのか、遅延時の実行計画がどうだったのかなどを調べることができます。
そこで、本記事では性能問題発生時の調査に必要な情報を取得するための設定や、性能遅延時の分析に有用な拡張を紹介します。
速報:PGConf.EU 参加レポート (Day 3)
PGConf.EU(PostgreSQL Conference Europe)は、欧州最大級のPostgreSQLコミュニティカンファレンスです。
PostgreSQLの開発者やユーザー、ベンダー企業が世界中から集まり、最新機能や開発動向、運用事例、技術的な知見を共有します。PostgreSQLコミュニティを代表する国際イベントの一つとして知られており、毎年多くの参加者が集まります。
2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。
本レポートでは、PGConf.EU 2026 Day3で発表された講演のうち、筆者が印象に残ったセッションを紹介します。
速報:PGConf.EU 参加レポート (Day 2)
PGConf.EU(PostgreSQL Conference Europe)は、欧州最大級のPostgreSQLコミュニティカンファレンスです。
PostgreSQLの開発者やユーザー、ベンダー企業が世界中から集まり、最新機能や開発動向、運用事例、技術的な知見を共有します。PostgreSQLコミュニティを代表する国際イベントの一つとして知られており、毎年多くの参加者が集まります。
2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。
本レポートでは、PGConf.EU 2026 Day2で発表された講演のうち、筆者が印象に残ったセッションを紹介します。
速報:PGConf.EU 参加レポート (Day 1)
PGConf.EU(PostgreSQL Conference Europe)は、欧州最大級のPostgreSQLコミュニティカンファレンスです。PostgreSQLの開発者やユーザー、ベンダー企業が世界中から集まり、最新機能や開発動向、運用事例、技術的な知見を共有します。PostgreSQLコミュニティを代表する国際イベントの一つとして知られており、毎年多くの参加者が集まります。
2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。
本レポートでは、PGConf.EU 2026 Day1で発表された講演のうち、筆者が印象に残ったセッションを紹介します。
【10/27 開催】PostgreSQL 19 リリース記念セミナー~ いよいよ登場!新機能の要点をコントリビューターが解説 ~
2026年秋、PostgreSQL 19が、いよいよ登場します。
PostgreSQLの最新情報を効率よく把握したい方に向けて、
SRA OSS主催の「PostgreSQL 19 リリース記念ウェビナー」を開催します!
Zabbix Summit 2026 参加レポート (Day 2)
2026年10月8日から9日にかけて、ラトビア共和国の首都リガにて開催されている Zabbix Summit 2026 に参加しております。
本記事では、2日間開催されるイベントの、2日目の様子をレポートいたします。
(1日目のレポートはこちら)
Zabbix Summit 2026 参加レポート (Day 1)
2026年10月8日から9日にかけて、ラトビア共和国の首都リガにて開催された Zabbix Summit 2026 に参加いたしました。
本記事では、2日間開催されるイベントの、1日目の様子をレポートいたします。
(2日目のレポートはこちら)
pgsql-hackersウォッチ(2026年9月)
今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年9月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。
PostgreSQLのデータ型を「なんとなく」で選ばない
PostgreSQLでテーブルを作るとき、保存する値が決まっていても、データ型の選択に迷うことがあります。注文コードには、長さを指定できるvarchar(n)を使うのか、textでよいのか。金額にはnumericを使うのか、円単位なら整数型でよいのか。日時や外部APIのレスポンスにも、複数の保存方法があります。




