问题标签 [gist-index]

从我能找到的信息来看，它们都解决了相同的问题——更深奥的操作，如数组包含和交集（&&、@>、<@ 等）。但是，我会对有关何时使用其中一种（或两者都不可能）的建议感兴趣。PostgreSQL 文档有一些关于此
的信息：

• GIN 索引查找比 GiST 快大约三倍
• GIN 索引的构建时间大约是 GiST 的三倍
• GIN 索引的更新速度比 GiST 慢十倍左右
• GIN 索引比 GiST 大两到三倍

但是，我特别想知道当内存与索引大小的比率开始变小时（即索引大小变得比可用内存大得多）时是否会对性能产生影响？我在#postgresql IRC 频道上被告知 GIN 需要将所有索引保存在内存中，否则它不会有效，因为与 B-Tree 不同，它不知道从磁盘读取哪个部分一个特定的查询？问题是：这是真的吗（因为我也被告知相反的情况）？GiST 有同样的限制吗？在使用其中一种索引算法时，我还应该注意其他限制吗？

我最近一直在优化我的 Postgres 数据库，而传统上，我只使用过 B-Tree 索引。但是，我在 Postgres 8.3 文档中看到 GiST 索引支持非唯一的多列索引。

但是，我看不出它们之间的实际区别是什么。我希望我的程序员同事能够解释它们之间的优缺点，更重要的是，为什么我会使用其中一个而不是另一个？

我正在使用 PostgreSQL 9.2 并且有一个 IP 范围表。这是SQL：

我在 和 上添加了普通的 B-treebegin_ip_num索引end_ip_num：

正在使用的查询是：

问题是我的BETWEEN查询仅使用begin_ip_num. 使用索引后，它使用end_ip_num. 结果如下EXPLAIN ANALYZE：

我已经尝试过各种索引组合，包括在begin_ip_num和上添加复合索引end_ip_num。

how can I detect GIN and GiST indexes in postgresql? I am looking for if an database of postgres use fulltext. I think that a table use GIN o GiST then is using fulltext.

I accept that GIN or GiST indexes does not necessarily mean that they are used for full text search, but how can I differentiate them of other indexes type? I want to list Gin an Gist indexes

我必须决定是对 hstore 列使用 GIN 还是 GiST 索引。

Postgres 文档状态：

• GIN 索引查找比 GiST 快大约三倍
• GIN 索引的构建时间大约是 GiST 的三倍
• GIN 索引的更新速度比 GiST 慢十倍左右
• GIN 索引比 GiST 大两到三倍

我解释它的方式，如果您需要查询很多，请使用 GIN，如果您需要更新很多，请使用 GiST。

在本次测试中，确认了上述 GIN 优于 GiST 的所有三个缺点。然而，除了 Postgres 文档中的建议之外，GIN 相对于 GiST（查找速度更快）的优势非常小。幻灯片 53 显示，在测试中，GIN 仅快 2% 到 3%，而 Postgres 文档中建议的速度为 200% 到 300%。

哪种信息来源更可靠，为什么？

让我们假设一个表：

排除约束应该不允许相同“barid”值的重叠“范围”值。但我希望它像其他值一样对待“NULL”（因此不允许具有 barid = NULL 的不同记录的重叠猪范围）。所以给定 a = NULL 和 b = NULL，我想实现“a IS NOT DISTINCT FROM b”类型的行为，而不是“a = b”一个（如此处所述）。这样的运营商存在吗？目前我只能通过使用来实现这一点

I can't use directly uuid with gist index

And I got this error:

ERROR: data type uuid has no default operator class for access method "gist"

HINT: You must specify an operator class for the index or define a default operator class for the data type.

我有一个简单的表，它有一个 user_birthday 字段，日期类型（可以是 NULL 值）

在该字段上定义了一个索引（btree），规则为 NOT user_birthday IS NULL。

试图跟进另一个想法，我添加了扩展btree_gist并创建了以下索引：

但它也没有影响，因为据我所知，它不用于范围检查。

PostgreSQL 版本是 9.3.4.0 (22) Postgres.app 并且问题也存在于 9.3.3.0 (21) Postgres.app

我对以下查询很感兴趣：

查询 #1：

查询 #2：

乍一看，两者应该有相同的执行计划，但由于某种原因，结果如下：

查询 #1：

查询 #2：

如您所见，<@ daterange没有使用现有索引，而使用了现有索引 BETWEEN。

需要注意的是，此规则的实际用例是在更复杂的查询中，这不会导致重新检查条件和位图堆扫描。在应用程序复杂查询中，这两种方法（有 120 万条记录）之间的差异是巨大的：Query #1 at 415ms Query #2 at 84ms。

这是日期范围的错误吗？难道我做错了什么？还是datarange <@按设计执行？

pgsql-bugs 邮件列表中也有讨论

我在 PG 9.3 中使用范围数据类型（启用了 btree_gist，但我认为这并不重要）。我有包含这些范围列的 GIST 索引。有些是int8range，有些是tsrange。

我想使用 WHERE 表达式进行查询，基本上说“右侧的范围为 NULL（无界）”。我该怎么写？

对于 tsrange，我可以做“tsrange @> timestamp 'infinity'”。但是 int8range 没有等价物。而且我认为为 int8range 正确执行此操作的方法也应该是 tsrange 的方法（不依赖于特定于时间戳的“无穷大”处理）。

该表达式应该可用于 GIST 索引（即属于这些范围类型的默认运算符类）。

帮助？

我有一个棘手的问题，试图找到一种有效的方法来订购一组包含大量（约 500 万）索引数据点的对象（约 1000 行）。就我而言，我需要一个允许我按特定数据点对表进行排序的查询。每个数据点都是一个 16 位无符号整数。

我目前正在通过使用一个大数组来解决这个问题：

对象表：

要点索引：

当我进行选择查询时，当前未使用此索引，而且我不确定它是否会有所帮助。

每天数组字段都会更新一组新的约 500 万个值

我有一个网络服务器，它需要列出按特定数据点的值排序的所有对象：

示例查询：

目前，执行此查询大约需要 2.5 秒。

问： 有没有更好的方法？我很高兴插入端在后台发生时很慢，但我需要选择查询尽可能快。这么说，插入需要多长时间是有限制的。

我已经考虑创建一个查找表，其中每个值都有自己的行 - 但我不确定这种方法会如何影响插入/查找时间，我怀疑输入 1000 多条记录，其中约 500 万个数据点作为单独的行会太慢了。

目前插入一行需要大约 30 秒，这目前是可以接受的。

最终，我仍在寻找基本问题的可扩展解决方案，但现在我需要这个解决方案才能工作，所以这个解决方案不需要进一步扩大规模。

更新： 我错误地认为拥有一个巨大的表而不是一个数组，而插入时间大大增加，查询时间减少到只有几毫秒。

我现在正在更改我的生成算法，以仅在它非零并且从以前的更新更改时才保存一个数据。这将插入减少到仅需要几秒钟的几十万个值。

新表：

新查询：

插入时间：15,000 条记录/秒

查询时间：17ms