你可能知道有一个名为ltree的PostgreSQL模块 . 此外，您还可以使用数组类型作为整数（* 1，请参阅下面的注释），在此测试中显示，与ltree相比，其递归查询实际上执行速度稍慢 - 除了字符串索引（* 2，见下面的评论） .
我不太确定这些测试结果的可信度 .
这里我最大的问题实际上是关于相对未知的，几乎没有文档的树模块 . 描述here（也可以找到文档!!）：
支持分层数据类型（类型的词典树），应该转到contrib / tree，因为缺少适当的文档而待决 .
阅读完文档后，我有点困惑，我是否应该以我的大应用程序为基础（一个CMS，一切都将存储在一个层次结构树结构中 - 不仅是内容，还有文件等，所以你可以看到这快速扩展）在ltree，普通物化路径（Path Enumeration）周围用分隔字符串或整数数组作为路径 - 或者理论上相对未知的“树”模块应该是更快，更可扩展和更好的解决方案 .
我已经分析了不同的树结构模型，由于查询性能，节点和子树的可伸缩性和重新排序是我的主要要求，我已经能够排除邻接列表（递归CTE不会解决性能，因为树缩放巨大），嵌套集/间隔（在一些查询中不够快，考虑到它在填充树时的缺点），闭包表（在复杂的树中非常大的缩放 - 对我这样的大型项目没有用）等等并决定采用物化路径，对于读取操作来说非常快，并且可以轻松地在子层次上移动子树和节点 . 所以问题只是关于物化路径的最佳建议实现 .
我对在PostgreSQL中听到你对“树”的理论或经验感到特别好奇 .
1 回答
据我所知，contrib / tree从未正式发布，而ltree被合并到PostgreSQL的核心 .
我理解两者都使用相同的标记路径的想法，但树只允许整数标签，当ltree允许文本标签允许全文搜索时，认为完整路径长度是有限的（最大65Kb，优选2Kb） .