问题标签 [ltree]

给定路径的唯一子节点（给定路径除外）

询问：

结果：

预期结果：

abc 的所有以下节点（结果不需要 abc）

我正在写一个评论系统。我已经能够按照这里的教程获得层次结构（http://www.postgresonline.com/journal/archives/173-Using-LTree-to-Represent-and-Query-Hierarchy-and-Tree-Structures.html )

但是，我无法通过投票来订购该行。我不能简单地ORDER BY PATH, n.upvotes在这里，因为同一线程上的回复会有不同的node paths. node_paths使用 计算public_key。

从例子中，给定

ban的节点路径分别c是a.b和a.c。我不能简单地从节点路径和它们中减去b和。如果我这样做，它将导致以下顺序：cORDER BY

这是有道理的，因为如果您public_key从中删除每一行node_path，它将简单地按最短node_path到最长排序。

如何编写一个查询，该查询将产生正确的层次结构并按如下方式排序：

在 PGAdmin 4 的创建表向导中，当您打开列类型下拉菜单时，有一个名为ltree_gist.

知道 GIST 可能是在ltree列上使用的最佳索引选项，我怀疑这ltree_gist只是ltree在其上定义了一个索引，因为只需一步即可创建一个ltree带有索引的类型列是合理的。GIST不过好像不是这样的！

长话短说，有人可以解释一下PGAdmin4 界面ltree之间的区别吗？ltree_gist

我在文档中找不到任何内容。

有人可以解释一下为什么在Postgresql 文档给出的示例中定义了两个索引机制（一个 btree 和一个 gist）（请查看F.21.4。示例部分）。

这是示例代码：

在最后两行，作者在路径列上创建了两个索引。为什么？这还不够 Gist 的目的吗？

在 F.21.3 节中，作者暗示 b-tree 和 gist 可以加速以下运算符：

ltree 上的 B-tree 索引：<, <=, =, >=, >

ltree 上的 GiST 索引：<、<=、=、>=、>、@>、<@、@、~、?

这意味着 Gist 对所有上述操作员来说已经足够了。让我澄清一下我的问题。作者是试图在这里为这两个索引提供示例，还是有使用这两个索引的原因。

我正在创建一个带有 ltree 列的表，我想知道我应该在我的列上创建两个索引（btree 和 gist）还是 gist 就足够了？

假设我想查找“活动”食谱的 ltree 路径，然后使用这些路径查找这些食谱的后代。

这是我的伪代码查询（这显然是不正确的）：

结果将为我提供以下路径的记录：

有没有办法在一个查询中正确地做到这一点？

我想使用 subltree 和列名在某个级别之后获取 Postgres ltree 层次结构。当我提供确切的输入但无法使用列名时，我能够获取。

这工作正常：

但这不是。请用正确的查询纠正我

我对 Postgres Ltree 很陌生。如果这里有任何问题，请纠正我

使用ltreePostgreSQL 扩展时，我们可以使用这两个运算符（以及其他运算符）将ltree列与lquerys 进行比较。

看来您应该~用于单个查询和?多个查询。但是，您也可以使用|逻辑 OR 运算符连接查询。

因此，在查询结果方面，这两者是等价的：

我应该更喜欢这些形式中的哪一种？

我正在使用 PostgreSQL 和 ltree 来构建大量二叉树数据。对于特定逻辑，我必须获取给定节点的最左/最右路径。

我的二叉树示例

我的表格内容示例

样本输入和预期输出：

输入 - 节点 1，最左边的孩子

输出 - 1, 1.L2, 1.L2.L3,... （仅最左边最外层的孩子）

我想在 postgresql、ltree 查询中得到这个结果。

请帮我解决这个问题。

任何更好的 postgre 表设计也可以提出，但必须在大量数据下获得良好的性能。

我需要将我的应用程序从 laravel 5 更新到 laravel laravel 7 我在少数列上使用 postgresql ltree，这是我的迁移代码

DB::statement("ALTER TABLE mytable ADD COLUMN mycolumn ltree");

该迁移在 laravel 5 上运行良好，但在 laravel 7 上却出现错误（我在同一台机器上运行它，已经安装了 ltree 扩展）

SQLSTATE [42704]：未定义对象：7 错误：字符 35 处不存在类型“ltree”

有人对此有解决方案吗？

谢谢

我正在开发的应用程序有一个名为folders. 文件夹可能包含其他文件夹，归用户所有，并且可以与其他用户共享。

该功能已经实现并且一直运行良好，直到最近某个特定的 API 端点开始表现不佳。此 API 端点返回调用用户拥有的所有文件夹。此外，对于每个文件夹，将返回有权访问该文件夹的用户列表（拥有用户将是其中之一）。

文件夹表的架构如下所示：

包含共享位的表如下所示，folder_visibility 表：

给定 profile_id 对文件夹的访问由 2 个规则决定：

1. (folder_id, profile_id)folder_visibility 表中存在一条记录，
2. 一个文件夹是另一个文件夹的后代，其中存在(folder_id, profile_id)记录。

或者，第一条和第二条规则可以这样表达：如果文件夹与用户共享，则用户可以看到该文件夹​​及其所有后代。

问题是有效地实施规则 2 对我来说似乎很难。

例子。以下是我的思考过程，以及测试数据：

1. 我获取给定配置文件的所有文件夹，这相对容易：

2. 从这里，我从上面完成规则 1，如下所示：

3. 为了实现规则 2，我天真地添加了另一组连接，最后得到了必要行的列表：

我的示例中最后一步的问题是执行计划变得非常庞大：

在大型数据集（给定配置文件的数千个文件夹）上，此查询会执行几秒钟。根据上述两条规则，获取所有文件夹以及每个文件夹的所有“可见性”的更有效方法是什么？