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