Mor*_*ryx 4 postgresql full-text-search
我一直在尝试使用 tsvector 索引进行全文搜索，并且看到在 tsvector 类型的列中生成一个存储向量是一种常见的做法。我们使用的是 Postgres 11.4，但我已经看到这种做法用作 PG 12 生成列的示例。（比出于相同目的使用触发器更简单。）
我的问题是，有什么好处？我在文本字段的 tsvector 上尝试了表达式 GIN 索引，并在存储的 tsvector 上尝试了 GIN 索引。本地大约有 800 万行，我无法测量任何有意义的速度差异。鉴于将向量存储为列和索引需要更多空间，我很好奇是否有明显的情况证明额外成本是合理的。例如，当您有更多角色时。
注意：我们将文本存储在数据库中，因此这不是您在不将源文本吸收到数据库中的情况下索引外部页面/文档/等的设置之一。
如果您使用邻近搜索（例如“phraseto_tsquery”），则使用功能索引必须将每个匹配的候选文档重新解析为 tsvector，并检查它的单词序列和间距是否正确。这可能会很慢，尤其是当候选人的数量远高于最终结果的数量时。如果存储了 tsvector，它可以只读取它而不重新解析文档，这要快得多。我认为“ts_headline”等其他高级功能可能处于相同的情况——但我还没有测试过它们。
即使你只是使用“@@”，我认为如果结果数量的位图不适合“work_mem”，那么它也需要重新解析文档以重新检查“溢出”的候选匹配块. 当然，在这种情况下，增加“work_mem”可能是比添加列更好的选择。
值得一提的是，如果您使用RUM而不是 GIN，它将解决功能索引上的短语到 tsquery 的问题。