问题标签 [b-tree-index]

I am using citext in PostgreSQL for all text column types. I wonder about citext performance.

I performed simple WHERE statement benchmarks over text columns that have a b-tree index, but I couldn't see any differences in terms of query cost.

For example:

These queries have identical query costs.

As far as I understand, citext stores the string as it is without converting it to lower case. So when a value is used in the WHERE clause, it uses the lower function for every comparison in each node of the b-tree index (I used a b-tree index).

If this is as I say, this should have caused performance problems, but it hasn't.

How does PostgreSQL achieve this?
How does PostgreSQL store citext column values in a b-tree index?

与 b 树索引相比，对具有低不同值的位图索引字段的查询是否更快？

与 b-tree 索引相比，位图索引在具有低不同值的字段上提供更好的查询性能的普遍想法。但这是真的吗？

例如， SELECT * FROM some_table WHERE color = 'RED'。这里该color字段具有较低的不同值，可以使用 b-tree 或位图索引进行索引：

• 如果color使用b-tree索引，那么为了执行上面的查询，数据库应该执行二进制搜索 + 中序遍历（从两个方向的二进制搜索结果），这给了我们 O(log N + K) ~ O(log N) 时间复杂度，其中 K - 是结果行数。K <= N。
• 如果color使用位图索引，那么数据库会进行一次完整扫描，这会产生 O(N) 时间复杂度。

所以，从我的角度来看，位图索引更糟糕。我对吗？

我正在尝试学习索引。我查看了工作中数据库中使用的实际索引。

我查看了两个随机索引：

这给出了：

这对我来说毫无意义；与实际表不同（column_name）不应该产生相同的数字吗？它没有！

..给 20273

TRANS_PK 是名为 NO 的列的索引。

...给出 4 328 622

我没有得到什么？选择不同的应该导致与“不同的键”相同的数字 - ALL_INDEXES 表中的列？

我创建了类似的索引

和，

并解释分析如下

情况1

案例二

案例 3

我对为什么会发生这种情况进行了足够的研究，但是任何地方都没有适当的解释。只有案例 3使用的是我创建的索引，而不是其他的。为什么会这样？

据我了解，案例 2搜索与列等效的字符串open_date，因此它不使用索引。但是为什么不是案例1。另外，如果我错了，请纠正我。

提前致谢！

编辑1：另外，我很高兴知道深入发生了什么。

以下是要点的摘录（https://gist.github.com/cobusc/5875282）

奇怪的是，PostgreSQL 将用于创建索引的函数重写为规范形式，但在 WHERE 子句中使用该函数时似乎没有这样做（为了匹配索引函数）。

尽管如此，我仍然不清楚为什么 postgres 的开发人员没有考虑获取任何附近的匹配索引（或者我的索引在我明确转换date为case 3之前是无用的）。考虑到 Postgres 是高度发展和可扩展的。

我有一个大约 270,000,000 行的表，这就是我创建它的方式。

我需要在init_package_details表上建立索引。

该表在 5-6 分钟左右创建。

我已经创建了 btree 索引，例如，

这需要 10 分钟（超过创建和填充表格本身的时间）

而且，当我创建另一个索引时，

它只是冻结并永远完成。我等了大约 30 分钟才手动取消它。

以下是iotop -o如果有帮助的统计数据，

• 当我创建平均大约 110-120 MB/s 的表时（这就是在 5-6 分钟内插入 2.7 亿行的方式）
• 当我创建第一个索引时，它的平均速度约为 70 MB/s
• 在第二个索引上，它以 5-7 MB/s 的速度缓慢增长

有人可以解释为什么会这样吗？无论如何我可以在这里加快索引创建速度吗？

编辑 1：没有其他连接访问该表。并且，在整个运行时间内pg_stat_activity显示为状态。active这发生在事务内部（发生在BEGIN和之间COMMIT，它在同一文件中包含许多其他脚本.sql）。

编辑2：

索引如何在内部维护？

分区的行为是否像二叉树？数据库 B 树索引的工作原理 - DZone 数据库

数据库内部的勇气和荣耀：B+Tree - DZone Database

在对表进行分区时，是否维护实际值参考。

对此的任何了解都可能会有所帮助。

Postgres 数据库问题：我正在尝试从工作* Drupal 8 安装中导入 Postgresql 10 数据库，但我遇到了这种类型的错误：

查询错误：错误：在“”“”或附近的零长度分隔标识符第 1 行：...ON“公共”。“drupal_menu_link_content_data”使用 btree (“”)

大约有十个这样的空 btree 索引字段实例：

CREATE INDEX "shortcut_field_data__shortcut_field_link_uri__idx" ON "public"."shortcut_field_data" USING btree ("");

在我导出数据库之前，我怎样才能安全地让 Drupal 提供一些东西来满足这些领域？

*或者，还有什么问题？（已编辑）

完整的空标签列表在这里：

创建索引 "drupal_QnV_yx12IV6LUDK8fiqQScOLltRLWh6lj73Z_u1PXWY_idx" ON "public"."drupal_menu_link_content_field_revision" 使用 btree ("");

在“公共”上创建索引“drupal_node__field_app_url__field_app_url_uri__idx”。“drupal_node__field_app_url”使用btree（“”）；

创建索引 "drupal_node__field_url__field_url_uri__idx" ON "public"."drupal_node__field_url" 使用 btree ("");

创建索引 "drupal_node__field_url__field_url_uri__idx" ON "public"."drupal_node__field_url" 使用 btree ("");

在“公共”上创建索引“drupal_node_revision__field_app_url__field_app_url_uri__idx”。“drupal_node_revision__field_app_url”使用btree（“”）；

创建索引 "drupal_node_revision__field_url__field_url_uri__idx" ON "public"."drupal_node_revision__field_url" 使用 btree ("");

创建索引 "drupal_shortcut_field_data__shortcut_field__link__uri__idx" ON "public"."drupal_shortcut_field_data" 使用 btree ("");

CREATE INDEX "menu_link_content_data__menu_link_content_field__link__uri__idx" ON "public"."menu_link_content_data" 使用 btree ("");

创建索引 "drupal_ui7U_4ySVsbBkDhd7CC2Cz97Yr_s3QEuF9xZI0mi1lA_idx" ON "public"."menu_link_content_field_revision" 使用 btree ("");

CREATE INDEX "shortcut_field_data__shortcut_field__link__uri__idx" ON "public"."shortcut_field_data" USING btree ("");

它们似乎都有链接或网址作为共同元素。但有些是节点，没有引用，然后是菜单。

我目前正在研究一种搜索功能，该功能最终会通过 LIKE 查询访问数据库。它曾经是这种形式 WHERE some_id = blah AND some_timestamp > blah AND (field1 LIKE '%some_text%' OR field2 LIKE '%some_text%' OR ...) ORDER BY some_timestamp DESC。由于该表的大小为数千万行，特别是当它在非常旧的时间戳上过滤时，这并没有很好地扩展。

经过一些研究，看起来三元组索引可能对文本搜索更有效。所以我在所有连接的文本字段上添加了一个三元索引，最初得到了很好的结果。尽管我发现了回归，但在更改了新查询之后。不再命中旧索引（some_id 和 some_timestamp DESC 上的 btree）。因此，新的文本搜索有助于过去非常慢的某些文本查询，以及由于 btree 索引而过去非常快（几毫秒）的其他文本查询现在超级慢（见下文）。

有没有办法两全其美？快速三元组文本搜索和快速 btree 索引，用于需要它的查询？

笔记：

• Postgres 11.6

• 我也尝试使用 btree_gin 索引来索引时间戳列，但性能几乎相同。

• 我稍微修改了我的查询（连接空白）以绕过三元索引并验证慢查询返回到 btree 索引和 <10ms 执行时间。

• 我尝试了一些查询重新排列，试图让两个索引都无济于事。

桌子：

三元索引：

询问：

解释：

我想在 Postgres 的 JSON 值中存储时间戳的列上创建一个索引。索引也需要转换为时区。这是我需要运行的查询，

我尝试将索引创建为：

1)

错误：“索引表达式中的函数必须标记为 IMMUTABLE ”

2)

错误：“没有函数匹配给定的名称和参数类型。您可能需要添加显式类型转换。 ”

3)

错误：“没有函数匹配给定的名称和参数类型。您可能需要添加显式类型转换”

我知道这不是创建索引的正确方法，因为这将是一种开销，但此时我不想更改我的数据插入逻辑。这就是为什么我需要创建一个索引。

我正在使用 Postgresql 9.4.8 版本。

是否有通用伪代码或相关数据结构来获取b 树的第 n^个值？例如，这棵树的第八个值是 13 [1,4,9,9,11,11,12,13]。

如果我有一些在 b 树中排序的值，我想找到第 n^个值而不必遍历整个树。这个问题有更好的结构吗？数据顺序可以随时更新。