通过 pg_roaringbitmap 优化标签查询的话，有没有必要做高频标签映射和结合普通复合索引？

我问了 DeepSeek ，它说 roaringbitmap 类型的值的元素的取值范围如果很大的话会影响效率。就是类似 INSERT INTO tag_content_bitmaps (tag_id, content_bitmap) VALUES(1, rb_build(ARRAY[1,100000])) 的内容查询效率会低于 INSERT ITO tag_content_bitmaps (tag_id, content_bitmap) VALUES(1, rb_build(ARRAY[1,2])) 。然后我就想到了一些花活。

首先，使用关系型数据库建立（标签 id ，内容 id ）复合索引之后如果标签的使用率不高的话，搜索效率还是可以的，但是如果标签的使用率很高，那么好像是因为区分度过低，所以搜索的效率会很低。但是 pg_roaringbitmap 对于高使用率的标签来说速度好像还是挺快的。但是就像前面第一段说的，这个也不是免费的。所以我不太敢全部标签都塞到 roaringbitmap 类型里。然后是具体的花活。

标签 id,标签名字,使用率
1,苹果,0.3
2,香蕉,0.01
3,梨,0.15
高频标签 id,原标签 id
1,1 //这个对应苹果
2,3 //这个对应梨

不过这还有问题，就是如何禁止高频标签建立索引，因为反正也不会用，还会占地方。可能最高效的方法是将低频标签全都复制到一个新表里？不过这个很反模式，也会导致维护麻烦。我问过 DeepSeek ，它给的方法感觉效率不怎么高的样子。

结合普通复合索引就是如果要搜索的标签同时包含高频标签和低频标签。那么就先在 roaringbitmap 里搜索那些高频标签，然后在结果中搜索满足低频标签的内容。或者可能反过来搜索效率更高？ DeepSeek 说前者效率更高。

这个高频和低频的分界线有没有比较好的建议？我目前定的是 3%。因为 DeepSeek 说 1% 到 5% 的使用率的标签建立索引还是可以的。

roaringbitmap 相关的表结构：

CREATE TABLE tag_content_bitmaps (
tag_id BIGINT PRIMARY KEY,
content_bitmap roaringbitmap
);
CREATE TABLE content_tag_bitmaps (
content_id BIGINT PRIMARY KEY,
tag_bitmap roaringbitmap
);

或者我这套花活是不是没什么大用？有没有更好的实现加速标签查询的方法？另外最好是 CPU 和内存要求低点，ES 之类的我怕钱包吃不消。

我跟 DeepSeek 聊的内容： https://chat.deepseek.com/share/dkuyx547fddet8vwwi 。

最后，再加点我个人的问题，答不答看你心情。这套花活我一个野生程序员能不能把持住？实际会不会很复杂？另外具体的 SQL 我应该肯定是写不明白了，我肯定会让 AI 写。但是我会写测试。我感觉这个测试还是比较好写的，用那种标准的运行两套代码对比结果就行了。一套简单低效几乎不会出错，一套复杂高效可能有错。