第46回 PostgreSQLアンカンファレンス@市ヶ谷
- nuko_yokohama
- 1443
- 3
- 0
- 54
ロジカルデコーディング、Decodeの部分までは意識してたけど、SnapshotBuilderやReoderBufferモジュールまでは知らんかった。#pgunconf
2024-03-23 13:50:26ReorderBuffer が WAL の中から「Tx 毎に」情報を集める感じになるらしい。なるほど。 #pgunconf
2024-03-23 13:52:01ReorderBufferは更新情報をトランザクションにまとめる役割を持っていると。なるほど。 #pgunconf
2024-03-23 13:52:18最終的に Tx が ABORT だった場合は buffer にためた内容を丸っと破棄するらしい。 #pgunconf
2024-03-23 13:53:17@kota2and3kan wal2json、扱いやすくていいですよ。SQLのJSON関数と組み合わせてPL/pgSQLでロジカルデコーダ組めたりします。 #pgunconf
2024-03-23 13:54:10logical_decoding_work_mem は ReorderBuffer とかの処理で使うメモリなので、デコード対象の全ての Tx のタプルの情報を格納する。メモリがあふれた場合は Disk 等に退避するらしい。 #pgunconf
2024-03-23 13:56:02サブトランザクションが1件INSERTのケースが非常に遅いと。へー。 #pgunconf 一番大きいTxの選び方は全探索O(n)。
2024-03-23 13:57:32@nuko_yokohama おぉ、なるほど。JSON 関数とも組み合わせられるんですね。JSON だとアプリ側でも扱いやすいでしょうし、よさそうですね。 #pgunconf
2024-03-23 13:57:42SAVEPOINTコマンド、ほとんど使ったことなかったから、あんまりサブトランザクション意識したことなかったなあ。 #pgunconf
2024-03-23 13:58:07合計10万件INSERTでも、10万サブトランザクションがそれぞれ1件INSERTだと、 Logical Decordingが遅い。 それぞれにSAVEPOINTやらEXEPTIONが入っちゃうから、 一番大きいトランザクションを探すのに苦労する。(O(n)) #pgunconf
2024-03-23 14:00:43線形ではなく、Binary Heapに変更しようとしている。 この場合、最大値の取得はO(1)、値の挿入はO(log n)になる。 来週コミットされれば、PostgreSQL 17入りになる。 #pgunconf
2024-03-23 14:02:47binary heapを使うときはmax connectionよりトランザクション数が多いときだから既存の用途にはほぼ問題ないらしい #pgunconf
2024-03-23 14:02:51With many concurrent transactions and subtransactions, evicting the largest one from the reorderbuffer can take time. Currently, we rely on a full scan to find it for eviction. His proposal for v17 is to use a binary heap for rapid identification. #pgunconf
2024-03-23 14:05:40ORM を使ってると裏で勝手に SAVEPOINT とかを使ってる場合があるので、気付かないうちにサブトランザクションが増えちゃったりすることもあるらしい。なるほど。 #pgunconf
2024-03-23 14:06:43ORマッパーを使ってると、10万サブトランザクションぐらいは、 平気で切ってくる(らしい)。 #pgunconf
2024-03-23 14:06:49> His proposal for v17 is to use a binary heap for rapid identification. postgresql.org/message-id/fla… #pgunconf
2024-03-23 14:07:42COPY FROMのフォーマット追加
すとうさんの発表。
内容としてはPostgreSQL開発のやりにくさ、という話になった。