ご存じかもしれませんが、ltree という PostgreSQL 用のモジュールがあります。また、整数に Array 型を使用することもできます (*1、以下のコメントを参照)。このテストでは、文字列のインデックス付けを除いて、ltree と比較して、再帰クエリで実際に少し遅く実行されることが示されています (*2、以下のコメントを参照してください）。
ただし、これらのテスト結果の信頼性についてはよくわかりません。
ここでの私の最大の質問は、実際には比較的知られていない、ほとんど文書化されていないツリー モジュールに関するものです。ここで説明されています（ドキュメントも見つけることができます!!）：
階層データ型 (一種の辞書編集ツリー) のサポートは、適切なドキュメントがないため保留中の contrib/tree に移動する必要があり ます。
ドキュメントを読んだ後、大きなアプリケーション (すべてが階層ツリー構造に格納される CMS) をベースにする必要があるかどうかについて少し混乱しています。コンテンツだけでなく、ファイルなども見ることができます。これはすぐにスケールアップします) ltree を中心に、パスとして区切られた文字列または整数配列を持つ通常のマテリアライズド パス (パス列挙) - または、理論的には比較的未知の「ツリー」モジュールが、より高速に実行され、よりスケーラブルで、2 つのより優れたソリューションである必要がある場合.
私はすでにさまざまなツリー構造モデルを分析しており、クエリのパフォーマンス、スケーラビリティ、およびノードとサブツリーの並べ替えが主な要件であるため、隣接リストを除外することができました (ツリーが巨大になるため、再帰 CTE はパフォーマンスを解決しません) ）、ネストされたセット/間隔（ツリーを操作するときの欠点を考慮すると、一部のクエリでは十分に高速ではありません）、クロージャーテーブル（複雑なツリーで大きくスケーリングするのはひどい-私のような大規模なプロジェクトには役に立ちません）などマテリアライズド パスは、読み取り操作が非常に高速で、サブツリーとノードを階層内で簡単に移動できます。したがって、問題は、Materialized Path の提案された実装の中で最も優れたものについてのみです。
PostgreSQL の「ツリー」に関するあなたの理論や経験を聞くことに特に興味があります。