日曜日に JJUG CCC に参加したばかりですが、PGCon 2023 と PostgreSQL新機能の話を聞くため&懇親会に参加するため再び東京へ。
昼頃まで予定があったのでギリギリの時間の新幹線を予約しましたが、八重洲の地下街への入り口を間違えてタイムロスしたので、会場に着いたタイミングでちょうど(澤田さんによる)本編が始まっていました。
PGCon2023での話題。
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
テスターが足りない、と。#jpug_study
開発者も増えてない、と。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
古くからある分野の開発者コミュニティあるある。これに加えて「ドキュメントの翻訳をしてくれる人が少ない」もありそう。
ロジカルレプリケーション関連のトークが多かった。
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
マルチマスター、みんなやりたいみたい。
(ときどきそういう話題を見る)#jpug_study
MySQL でも見ますが。
BRINの検索範囲が広がらないように、例えばmin/max/の情報の代わりにBloomフィルタを入れられるようにできるようにしたり、という機能拡張の話があった。
— たいき (Taiki) (@taikik1222) 2023年6月10日
PostgreSQL 14以降の話だそう。#jpug_study
アンカンファレンスは発表ではなく議論中心。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
確かに、発表中心でやっているのは日本の PostgreSQL アンカンファレンス(オンライン)ぐらいしか見たことがないかもしれません。
glibcのバージョンアップにともなう問題は意識したことまだなかったな…
— ester@VFR1200F (@ester41) 2023年6月10日
気をつけないと #jpug_study
アンカンファレンスは20個以上のセッション。プレゼンより議論中心。ロジレプの話、pg_upgrade改善、PGConのこれから、など。
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
次回のPGConはオタワではないらしい。 #jpug_study
関係ないですが「オタワ」を「オワタ」と空目しがちです。
帰り道、飛行機が遅れて乗り継げず「トロント観光してね♥️」みたいなスケジュール変更を提案される。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
おうちに帰るまでがカンファレンス…
— ester@VFR1200F (@ester41) 2023年6月10日
エアカナダの人手不足による帰宅難民は悲しすぎる #jpug_study
トロントで2日後の成田行きに予約変更されるも、交渉の末、1日後の韓国経由で帰国…#jpug_study
— たいき (Taiki) (@taikik1222) 2023年6月10日
後から懇親会で聞いた話では、運よく間に合って乗り継ぎ出来た組と間に合わず足止めを食らった組に分かれてしまったようでした。
セミナー後半。PostgreSQL 16の話。
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
#jpug_study
PostgreSQL 16のリリースノートと虎の巻でわいわい言う会、今年もやります! #jpug_study
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
MySQL のアップデートサイクル(マイナーバージョンで機能追加・変更・削除)で麻痺していましたが、PostgreSQL は年 1 のバージョンアップでしたね(マイナーバージョン・リビジョンで修正は入るとして)。
ほかのイベントと被っちゃったけど後半だけ参加しようかな?https://t.co/H9KLbXBY67#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
PostgreSQL 16はロジレプまわりの機能追加が多い。
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
最初はoriginの話。
#jpug_study
ロジカルレプリケーションが並列適用に対応。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
MySQL も MTS 改め MTA(マルチスレッドアプライヤー)に対応していますし。
Logical ReplicationのCREATE SUBSCRIPTIONに origin オプションが追加になった。
— たいき (Taiki) (@taikik1222) 2023年6月10日
origin=noneにすると、2段階以上伝播しなくなるので、双方向でレプリケーションを組んでいる場合に、ループしなくなる。
ただ、マルチマスターは、まだ無理。
(競合の解決ができない)#jpug_study
originを使った双方向レプリケーションのWAL循環防止と、それでは防げない競合の話。https://t.co/r0AKUxU8nP
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
#jpug_study
ぬこさんが以前 PostgreSQL アンカンファレンスで発表された話。
1トランザクションで重数ギガレベルの更新がある場合、ロジカルレプリケーションの遅延が発生するからすぐに送ってくれるのはありがたい! #jpug_study
— ester@VFR1200F (@ester41) 2023年6月10日
それから、 run_as_owner オプションが追加された。
— たいき (Taiki) (@taikik1222) 2023年6月10日
true にすると、Logical Replicationの適用をテーブルのオーナーが実施するようになる。
(デフォルトはfalseで、この場合は従来通りAdminユーザ)#jpug_study
ロジカルレプリケーションの機能改善を見ながら、SupabaseのRealtimeがどうアップデートされていくのか気になっている。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
レプリケーション関連の個人的な興味はここです。
VACUUMが使うリングバッファのサイズ指定が可能に。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
VACUUMに BUFFER_USAGE_LIMIT が追加された。
— たいき (Taiki) (@taikik1222) 2023年6月10日
VACUUMが使用するリングバッファのサイズを指定可能になり、
0はリングバッファを使用しない、あとは128k~16GBの実サイズで指定。#jpug_study
VACUUM 大事。
SQL/JSONの新機能、15ではリリース前にrevertされちゃったけど16では入ってきた。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
JSON_ARRAY()、JSON_ARRAYAGG()、JSON_OBJECT()、JSON_OBJECTAGG()が追加された。
— たいき (Taiki) (@taikik1222) 2023年6月10日
SQL標準に規定されているものだそうで。#jpug_study
reserved_connectionもスーパーユーザ外でコネクションを抑えておくと言う考えで、やっぱクラウド向け感、、 #jpug_study
— こば @レイオフ⇒DB関連の職探し中 (@tzkb) 2023年6月10日
非スーパーユーザー用にコネクションを確保できるように。
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
MySQLでは管理者コネクションが別に確保できるようになってたはずだけど考え方が違う?#jpug_study
PostgreSQL と MySQL で微妙にアプローチは違うとはいえ、クラウドのマネージドサービスを意識した機能追加・変更は増えている気がします。
ベータ版がリリースされてから正式リリースまでにテストしてくれる人が不足しているらしいよ! #jpug_study
— まぐろ; (椎間板ヘルニア) (@tameguro) 2023年6月10日
冒頭の話、再び。
終わりそうに見せかけて続き。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
並列COPY性能向上。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
と、思いきや…
並列COPYの性能が15より悪化してるのはアカンー #jpug_study
— ester@VFR1200F (@ester41) 2023年6月10日
罠が。
PostgreSQL 16機能おまけ
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
並列COPYの性能向上の話。
ロック保持処理を減らしたはず・・・なんだが、並列度が小さいときは、PG16のほうが処理時間がかかるという面白い結果に。4並列のときが一番時間がかかるというのが面白い。 #jpug_study
時間が余ったので、ここから先は高塚さんのお話でした。
続いて高塚さんから、PostgreSQLで列指向格納、の話。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
ZedStore・・・そういえば開発止まってましたね。 #jpug_study
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
Citusはシャードなしで列指向格納はできる・・・がパラレル動作しないという問題がある。 #jpug_study
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
Fujitsu Enterprise Postgresってインメモリのカラムナストアがあるの。知らんかったー。 #jpug_study
— こば @レイオフ⇒DB関連の職探し中 (@tzkb) 2023年6月10日
Arrow FDWの話もでてきた。PG-Stromが使える環境でないと実質的に無理そう。 #jpug_study
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
Parquet FDW、めっちゃ便利じゃん! #jpug_study
— そーだい@初代ALF (@soudai1025) 2023年6月10日
S3にある Parquet S3 FDW めちゃめちゃ便利じゃん!! RDS、対応してくれ!!!! #jpug_study
— そーだい@初代ALF (@soudai1025) 2023年6月10日
PostgreSQLだけあってFDWの選択肢が複数出てくる。#jpug_study
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
個人的な感想はこれ。ちなみに AWS の Redshift などは「PostgreSQL ベースだけど PostgreSQL じゃないから対象外」とのこと。
興味のある列が3割未満なら列指向ストレージを活用するとパフォーマンスに優位性がある #jpug_study
— そーだい@初代ALF (@soudai1025) 2023年6月10日
Parquet vs CSV。
— ぬこ@横浜 16beta1 (@nuko_yokohama) 2023年6月10日
演算対象の列が10%くらいになると効果があるっぽい。
自分でも実験してみようかしらん。
#jpug_study
このあたりで本編は終了。
懇親会では NTT データの加藤さんを含め、若手の皆さんが 2 人いる席へ。
また、先月の名古屋開催の技書博で行き違いになってしまった、まぐろさんも一緒になりました。
若手の皆さんはサポートに関わる業務も担当されているとのことでしたが、個人的に大きなカルチャーギャップを感じたのは、
「電話でのやりとりは一切していない」
という点。
わたしの勤務先は、顧客に「アナログのほうが得意な層」が多く含まれているので電話窓口を無くしてしまうと成り立たないです。
高校・大学から新卒で入ってすぐのメンバーも(Web アプリケーション開発はもちろん、顧客の業界である各種士業についても)知識も経験もない中で、子供の頃から全く慣れ親しんでいない電話を使ってコミュニケーションを取り問題を解決に導くのは、世代を考えると実はかなり高度なスキルなのでは?と思ったり。
それ以外では、クラウドのサービスを触る機会が少ない人が意外と多そうだったのが印象的でした。
このあたりは、日本のユーザーコミュニティへの参加者層の兼ね合いもありそうです(MySQL のほうが「DBMS 開発者」「DBMS サポート提供者」ではない純粋な「ユーザー」の参加が多そうですし)。
あとは、まぐろさんの次回作に期待!という話もしたのですが、
「読者が何を望んでいるのか分かりづらいから本のテーマ・内容が決めづらい」
…確かに。
日本の RDBMS 界隈を取り巻く状況がよくわかる(?)気がします。
持ち帰れるものをチョイスしたら謎の組み合わせになりました。
— hmatsu47(まつ) (@hmatsu47) 2023年6月10日
(右は仙台ぽい?)
ありがとうございました!#jpug_study pic.twitter.com/frZKwruGzY
懇親会のジャンケン大会では、岡山名物ちび桃きびだんご(マスカット)と、仙台弁こけしコースターをいただきました。
ありがとうございました。