10 分枠→ 20 分枠へ移動して 2 ネタ用意しての発表参加でした。
枠移動で申し込み順が 20 分枠の最後になった関係で、最終枠（22:05-）が割り当てられました（なお当日は朝 4:00 から少し仕事をする必要があり、朝 3:30 過ぎに起きていました）。
…結局（予想どおり？）前のほうから延長に延長を重ねてどんどん遅れていき、自分のパートは 22:30 開始となりました。
発表それぞれ
資料非公開でタイトルを覚えていないものもあるのでざっと振り返っていきます。
トップバッターは一時帰国中の AWS 澤田さんでした。「ベンチマークは難しい」ということで、
- PostgreSQL 16 と 17 でシチュエーション別の Vacuum 所要時間の比較をしたときに原因がよくわからない性能改善が見つかった
- 調べてみたところ16 では WAL に関連する Vacuum 処理と Vacuum 用のリングバッファの容量不足が関係していた（17 でバッファサイズを増やしていた）
- それにしても他のケースで同じような性能差が出ないのはおかしい、と思ってさらに調べたところ、差が出なかったケースではリングバッファを使う必要がなかった
というケースの話をされていました。
Loggedの場合のVacuumがv16でやたら遅かった。
— たいき (Taiki) (@taikik1222) 2025年6月24日
Perfを取ったら、GetVictimBuffer() がやたら実行されていて、
その延長で、 XLogFlush() も呼ばれていた。
なんでだろう、と思って調査してみた。#pgunconf
Vacuumでは、共有バッファを汚さないように、別にバッファを持って処理をしている。
— たいき (Taiki) (@taikik1222) 2025年6月24日
しかし、Vacuum中にこれがいっぱいになると、追い出す必要があるが、ディスクに書かれていないので、追い出す前に書き込む必要がある。(XLogFlush()が呼ばれた原因)#pgunconf
16で遅かったのが17で早くなったのは、リングバッファサイズが大きくなったから。普段全然気にしないところでもチューニングの余地あるんだな……。 #pgunconf
— まぐろ; (椎間板ヘルニア) (@tameguro) 2025年6月24日
Denseケースで発生せず、Sparseケースでは発生しなかったのは、どうも、たまたまだったっぽい。
— たいき (Taiki) (@taikik1222) 2025年6月24日
Tidインデックスの右隣のLeafページが、Vacuumが目的とするページだったので、バッファを使わなかった。
(こういうのを、Corner Caseって言うんだろうな…)#pgunconf
続いての近藤（たいき）さんはご自身の近況報告でした。
- 祝入籍！
- ところが急遽家を退去しないといけなくなった
- 新居の部屋の広さの関係で 7 色に光る PC を持って行けず、開発環境がなくなってしまった
- 会社の人が代わりに（？）pgmaster2 に全文検索機能をコントリビュートしてくれた
怒涛の数ヶ月間（？）の話でした。
Good & Big News!!
— hmatsu47(まつ) (@hmatsu47) 2025年6月24日
㊗️入籍！
#pgunconf
転居の話が結婚関連でいい話っぽいのかと思いきや、まさかのpgmaster2の開発が止まってしまうというbad news#pgunconf
— tkyk04 (@taka_yuki_04) 2025年6月24日
七色に光るマシンに危機が！
— hmatsu47(まつ) (@hmatsu47) 2025年6月24日
#pgunconf
OSS として開発が始まったけど、社内で (業務で) 改善が実施された結果、改善部分が外部に出せるかわからなくなった問題。なるほど。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
続いて加藤さんから Visibility に関するフラグと可視性判定の話がありました。
（資料があるので概要は省略）
PageHeaderData の pg_flags にはいろんなフラグが入っている。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
ISOLATION LEVEL が違うとスナップショットを取得する動作が違うらしい。READ COMMITTED だと SQL 毎、REPEATABLE READ or SERIALIZABLE だと Tx 毎、って感じっぽい。知らなかった。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
なるほど、自分が INSERT したデータが可視か否かを判断する時に cid を使ってるのか。知らなかった。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
その次はこばさんから pg_duckdb と DuckLake の話がありました。
（スライドではなく Zenn 記事を参照しながらの説明でした）
何か DB 周りで新しいものが出てくると、わりと良く「PostgreSQL 用の extension」が出てくる気がする。PostgreSQL すごい。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
DuckDB、比較的小さなデータセット (～300GB) の分析にはいい感じだけど、TB ぐらいのサイズになってくると DuckDB でちょっとキツイ、的な調査結果もあるらしい。データセットが TB になってくると Spark とかを使った方が良いっぽい。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
pg_ducklate って extension にいい感じに統合する案が提案されてるらしい。#pgunconf https://t.co/bRCBzbVKvi
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
白石さんからはトランザクション分離レベルの話がありました。
やはり READ COMMITTED だと速いらしい。REPEATABLE READ と SERIALIZABLE で結果がほとんど変わってないのは何故なんだろうか。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
TPC-B自体がスナップショット分離で実行しても直列化可能なスケジュールしか生成されず、直列化異常によるアボートが発生しないためです。逆に、write skewが発生するようなワークロードで検証すれば、スナップショット分離よりも直列化可能の方が性能が大幅に劣化すると考えられます。
— Youki Shiraishi (@y_sira) 2025年6月24日
この「ベンチマークがエラーで落ちて困る」話、別のところで最近聞いたなー
— hmatsu47(まつ) (@hmatsu47) 2025年6月24日
と思ったら池田さんの話だったか#pgunconf
かつては pgbench がエラーで止まって同じような性能比較ができなかった話については、ちょうど先日の JPUG 総会併設セミナーの中でも触れられていましたね。
スナップショット分離が最初に定義されたのは 1995年らしい。歴史だ。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
「説明が丁寧でやさしいTsurugi」みたいなセッションになってる気がしないでもない#pgunconf
— hmatsu47(まつ) (@hmatsu47) 2025年6月24日
話が理解できたわけではないのですが。
Honda さんからは Rails での PostgreSQL 18 対応における仕様変更（cancel request key 長変更）の取り扱いについての話がありました。
PostgreSQL の新バージョンに合わせて ORM 側でも新機能の追従作業を実施するの、大変そうだなぁ。リリース前に情報をキャッチアップして準備が進められてるの、すごい。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
Protocol 3.2 (v18以降)で cancel request keyが長くなった。
— たいき (Taiki) (@taikik1222) 2025年6月24日
これに対応しないと、クエリのキャンセルが取り扱えない…#pgunconf
ああrevertこわい#pgunconf
— hmatsu47(まつ) (@hmatsu47) 2025年6月24日
本体（PostgreSQL 18）のほうで変更が revert されてしまうと、せっかくおこなった変更を取り消さないといけないので。
そしてわたしからは、前日の JAWS-UG AI/ML 支部で話した GraphRAG 向けのインデックスと pgvectorscale のアップデート情報について話しました。
最近は Agent とか MCP とか A2A とかのお話が多くて、RAG とか Vector とかのお話が減っている気がしますね... 技術の変遷の流れが速い...#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
PostgreSQL + pgvector でサポートしてない機能を、AI coding を使って他所から移植してみたらしい。すごい。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
今回はLlamaIndexを使ってましたけど、LangChainでもできるものなんですかね？#pgunconf
— たいき (Taiki) (@taikik1222) 2025年6月24日
やろうと思えばできると思いますが、今回は参考になるRDB向けの実装がLlamaIndexにしかなかったのでそちらでやってみました
— hmatsu47(まつ) (@hmatsu47) 2025年6月24日
TimescaleDB が TigerData にリブランドしたらしい。知らなかった。#pgunconf
— こたつ&&みかん (@kota2and3kan) 2025年6月24日
pgvectorscale そのものよりも開発元の Timescale 社の TigerData へのリブランディングの話のほうが反応が大きかったです（資料には書かなかったのですが）。
最近の pgvector 、あまり盛り上がってないらしい…
— たいき (Taiki) (@taikik1222) 2025年6月24日
Version 0.8.0で、バージョンアップが止まってしまっている…#pgunconf
まあひととおり必要な機能が 0.8.0 で揃った、とも言えるのですが。
そんな状況なので pgvector の改良版である pgvectorscale は全然話題にならないですね。
（DiskANN の本家 Microsoft の pg_diskann も話題になっているようには見えず…）
