所以,我在网站上找到一篇文章,postgres 中有 3 种类型的索引。我决定创建第一个简单的。
// добавляю специальное поле типа tsvector
ALTER TABLE "Doc" ADD "tsv" tsvector;
// обновляем это поле лексемами
update "Doc" set "tsv" = to_tsvector("text");
// уже создаем индекс на основе этого поля
create index tsv on "Doc" using gin("tsv");
磁盘上的初始数据库占用 1GB,但在生成令牌的第二阶段,数据库增长了 2 倍,而在创建索引本身的最后阶段,又增长了 400mb。
我有一个问题,这正常吗?我做对了吗?是否需要有一个中间字段来生成令牌?像tsvector?或者也许没有它?
6 实际上:btree、hash、gist、spgist、gin、brin。这只是开箱即用。分叉和扩展中可能还有其他人。正确开发一个新
index access method
的不是最简单的任务——但它是可能的,甚至不需要更改 DBMS 本身的源代码,为此有足够的扩展。Postgresql 是一个 MVCC DBMS,即 该表可以同时具有同一行的不同版本,更新看起来像删除+插入。因此,通过这个简单的查询,表的大小正好翻了一番,这就是它应该的样子。然后自动清理过程将出现,将删除的行标记为空白空间。后续的插入和更新会占用表开头的空间,文件尾部的空页可能会返回给文件系统。好吧,或者执行
vacuum full
更快地返回空间(独占表锁,无锁 - 第三方实用程序 pgcompacttable,pg_repack)每 GB 数据集 400MB 的 gin 索引 - 看起来相当充足。
在一般情况下,不需要中间字段,您可以直接通过请求具有此类功能索引的索引来跟踪它:
相应地执行搜索查询,
where to_tsvector('english', "text") ..
而不是where tsv ...
构建索引需要指定全文搜索配置的名称。也许你不感兴趣
english
。使用哪一个而不指定配置 - 确定设置default_text_search_config