私はリスボンの壮大な街で一週間を過ごし、毎年恒例のヨーロッパのPostgeSQL会議に出席しました。これは、最初のヨーロッパPostgreSQL会議から10周年を迎え、6回目の参加となりました。
第一印象
街は素晴らしく、雰囲気も素晴らしく、知的でフレンドリーな人々との興味深い会話でいっぱいの非常に生産的で有益な一週間になるようでした。ですから、基本的に私がリスボンで最初に学んだクールなことは、リスボンとポルトガルがどれほど素晴らしいかということですが、話の残りの部分ではあなたがここに来たと思います！
共有バッファ
トレーニングセッション「日常業務用のPostgreSQLDBAツールベルト」に参加しました
Kaarel Moppel（Cybertec） 。私が気づいたことの1つは、shared_buffersの設定でした。 shared_buffersは実際にはシステムのキャッシュと競合または補完するため、使用可能なRAM全体の25％から75％の間の値に設定しないでください。したがって、一般に、一般的なワークロードの推奨設定はRAMの25％ですが、特殊なケースでは75％以上に設定できますが、その中間ではありません。
このセッションで学んだその他のこと：
- 残念ながら、データチェックサムのオンライン（またはオフライン）での簡単なアクティブ化/有効化はまだ11ではありません（initdb /論理レプリケーションが唯一のオプションのままです）
- vm.overcommit_memoryに注意してください。2に設定して無効にすることをお勧めします。vm.overcommit_ratioを約80に設定します。
高度な論理レプリケーション
Petr Jelinek（第2象限）の話で 、論理レプリケーションの元の作成者である私たちは、この新しいエキサイティングなテクノロジーのより高度な使用法について学びました。
- 一元化されたデータ収集：複数の発行元と、それらの各発行元へのサブスクライバーを備えた中央システムがあり、さまざまなソースからのデータを中央システムで利用できるようにします。 （通常の使用：OLAP）
- 共有グローバルデータ、つまり、1人以上の加入者に公開するグローバルデータとパラメータ（通貨、株式、市場/商品価値、天気など）を維持するための中央システム。その後、これらのデータは1つのシステムでのみ維持されますが、すべてのサブスクライバーで利用できます。
- 論理レプリケーションは非同期にすることも同期することもできます（コミット時に保証されます）
- 論理デコードの新しい可能性：
- 論理デコードプラグインを介したDebezium/Kafkaとの統合
- wal2jsonプラグイン
- 双方向レプリケーション
- ダウンタイムをゼロに近づけるアップグレード：
- 新しいサーバーで論理レプリケーションをセットアップします（データチェックサムを有効にしたinitdbの場合もあります）
- ラグが比較的小さくなるまで待ちます
- pgbouncerからデータベースを一時停止します
- ラグがゼロになるまで待つ
- pgbouncerの構成を変更して新しいサーバーを指すようにし、pgbouncerのconfをリロードします
- pgbouncerからデータベースを再開します
PostgreSQL11の新機能
このエキサイティングなプレゼンテーションでは、 Magnus Hagander（Redpill Linpro AB） PostgreSQL 11の素晴らしさを紹介してくれました：
- pg_stat_statementsは64ビットのqueryidをサポートします。
- pg_prewarm（システムのキャッシュまたは共有バッファをウォームアップする方法）：新しい構成パラメータの追加
- postgres（つまりユーザー:)）から簡単に離れることができる新しいデフォルトの役割
- xactional制御を使用したストアドプロシージャ
- 強化された全文検索
- 論理レプリケーションはTRUNCATEをサポートします
- ベースバックアップ（pg_basebackup）はチェックサムを検証します
- クエリの並列化におけるいくつかの改善
- 10よりもさらに洗練されたパーティション分割
- デフォルトのパーティション
- パーティション間で更新（行をあるパーティションから別のパーティションに移動）
- ローカルパーティションインデックス
- すべてのパーティションにわたる一意のキー（まだ参照できません）
- ハッシュ分割
- パーティションごとの結合
- パーティションごとの集計
- パーティションは、異なる外部サーバーの外部テーブルである可能性があります。これにより、きめの細かいシャーディングの大きな可能性が開かれます。
- JITコンパイル
zheap：PostgreSQLBloatWoesへの回答
これはまだ11にはありませんが、非常に有望に聞こえるので、クールなもののリストに含める必要がありました。プレゼンテーションはAmitKapila（EnterpriseDB）によって行われました。 代替の種類のヒープとして最終的にPostgreSQLコアに統合されることを目的としたこの新しいテクノロジーの主要な作成者の1人。これは、PostgreSQLの新しいPluggable Storage APIと統合され、複数のテーブルアクセスメソッドをサポートします（私の最初のブログで取り上げたさまざまな[インデックス]アクセスメソッドと同じ方法で）。
これにより、PostgreSQLの慢性的な欠点を解決しようとします：
- テーブルの膨張
- （自動）掃除機が必要
- トランザクションIDのラップアラウンドの可能性
これらはすべて、平均的な中規模から大規模のビジネスにとっては問題ではありませんが（これは非常に相対的ですが）、数十TBのデータと数千のトランザクション/秒のPostgreSQLを問題なく実行している銀行やその他の金融機関を知っています。テーブルの肥大化は自動バキュームによって処理され、行のフリーズはトランザクションIDのラップアラウンドの問題を解決しますが、それでもこれはメンテナンスフリーではありません。 PostgreSQLコミュニティは、真にメンテナンスフリーのデータベースに向けて取り組んでいるため、zheapアーキテクチャが提案されています。これにより、次のことがもたらされます：
- 新しいUNDOログ
- UNDOログは、古いバージョンを参照して古いトランザクションにデータを表示します
- UNDOは、中止されたトランザクションの影響を元に戻すために使用されます
- 変更はその場で行われます。古いバージョンはデータファイルに保持されなくなりました。
高レベルの目標：
- より優れた膨張制御
- 書き込みが少ない
- 小さいタプルヘッダー
これにより、PostgreSQLはこの点でMySqlやOracleと同等になります。
PostgreSQLの並列クエリ：（誤）使用しない方法
AmitKapilaとRafiaSabih（EnterpriseDB）によるこのプレゼンテーションでは、並列化の内部ビットと、よくある間違いを回避するためのヒント、およびいくつかの推奨されるGUC設定について学びました。
- 並列処理はBツリーインデックスのみをサポートします
- max_parallel_workers_per_gatherを1→4に設定（使用可能なコアによって異なります）
- 次の設定に注意してください：
- parallel_tuple_cost：1つのタプルを並列ワーカープロセスから別のプロセスに転送するコスト
- parallel_setup_cost：並列ワーカーの起動と動的共有メモリの初期化のコスト
- min_parallel_table_scan_size：並列シーケンススキャンで考慮されるリレーションの最小サイズ
- min_parallel_index_scan_size：並列スキャンで考慮されるインデックスの最小サイズ
- random_page_cost：ディスク内のランダムページにアクセスするための推定コスト