PostgresヒープとSQL Serverのクラスター化インデックス
私はSQL ServerからPostgresに移行しています。私がダイジェストする最大のことの1つは、Postgresでデータを並べ替える「クラスター化されたキー」が存在しないことです。
Postgresが内部的にでソートされたデータセットの必要性をどのように回避したか、およびそれが大規模なヒープテーブルでどのように機能し、例外的なパフォーマンスを提供するかについて、誰かが意見を共有できますか？
より少ないロックでpg_repack拡張機能をオンラインでクラスター化することができます
PostgreSQLは単にこの機能を実装していません。それを実装しないというトリックはありません。それは、単純な、単純化された方法で実装されていないだけです。専門用語を1つ使用するために、PostgreSQLのすべてのbtreeインデックスは「セカンダリインデックス」であり、「プライマリインデックス」ではありません。主キーのインデックスでさえ「二次インデックス」です。
クラスター化されたキー（または別の製品がそれらを呼び出すインデックス化されたテーブル）が重要な場合があり、そのような場合、PostgreSQLは「例外的なパフォーマンスの提供」に失敗します。もちろん、それらのケースがどれほど一般的であるかについて議論することもできますが、それらは確かに存在し、PostgreSQLがそれらのソリューションを提供していないのは残念です。これに対処するための提案はありますが、それらの取り組みのいずれも現在活発ではないと思います。
場合によっては、CLUSTERコマンドを使用するか、パーティショニングを実装するか、カバリングインデックスを使用することで問題を改善できますが、実際のクラスタリングに代わるものとして完全に満足できるものはありません。
PostgreSQLは、クラスター化インデックスの「必要性」を置き換えるために特別なことは何もしません。
単にその機能がないだけです。 （ 誰かが言うだろう それは大きな損失ではありません。）
CLUSTERまたはpg_repackを使用して、手動で1回限りのクラスターを実行できます。
宣言的なパーティション分割もあります（ただし、PostgreSQL 11までは多くの注意事項があります）。これは完全なクラスタリングではありませんが、行を指定されたバケットにグループ化するために使用できます。