子查询中直接调用to_tsvector()会导致重复计算、索引失效和性能骤降；应预先物化tsvector字段并建立GIN索引，或先过滤ID再JOIN，避免在WHERE或ORDER BY中嵌套高开销函数。
子查询里直接用 to_tsvector() 会拖慢查询速度
很多人想在 WHERE 子句里写 (SELECT to_tsvector('english', content) FROM posts WHERE id = t.post_id) @@ to_tsquery('english', 'bug')，结果发现执行计划里反复调用 to_tsvector()，没走索引，10万行查起来秒变5秒+。
根本原因是：子查询每次被外层驱动时都重新计算向量，无法复用，GIN 索引也完全失效。
- 必须把
tsvector字段提前物化（比如加个tsv列并建 GIN 索引） - 子查询若只用于过滤，应先查出 ID 集合，再 JOIN 或 IN，而不是在条件里现场转
- 如果真要嵌套，优先用
LATERAL+ 预计算列，例如：FROM articles a, LATERAL (SELECT to_tsvector('english', a.title || ' ' || a.body)) AS t(tsv)
@@ 操作符不能跨表隐式转换，子查询返回 tsvector 必须显式类型对齐
写 WHERE (SELECT tsv FROM search_cache WHERE post_id = p.id) @@ to_tsquery(...) 时，PostgreSQL 可能报错 operator does not exist: tsvector @@ text ——不是因为子查询为空，而是子查询返回 NULL 时，@@ 左操作数变成 UNKNOWN 类型，类型推导失败。
- 务必用
COALESCE((SELECT tsv ...), ''::tsvector)避免 NULL 传播 - 子查询若返回多行，
@@会直接报错“more than one row returned”，必须确保单行（加LIMIT 1或用聚合） - 更稳妥的做法是把子查询结果作为派生表，显式声明列类型：
(SELECT tsv::tsvector FROM ... LIMIT 1) AS q
用子查询预过滤 ID 再 JOIN tsvector 字段，才是高效组合方式
比如要查“标题含 database 且评论数 > 5 的文章中，正文匹配 ‘replication’ 的那些”，别在一层里堆逻辑。拆开更可控：
SELECT p.*
FROM posts p
JOIN (
SELECT id
FROM posts
WHERE title @@ to_tsquery('english', 'database')
AND comment_count > 5
) AS filtered ON p.id = filtered.id
WHERE p.tsv @@ to_tsquery('english', 'replication');- 内层子查询可走
title上的 GIN 索引（如果建了）或普通索引 - 外层
WHERE p.tsv @@ ...走的是tsv列的 GIN 索引，不重复计算 - 避免在子查询里出现
to_tsvector()、ts_rank()这类高开销函数
复杂排序 + 子查询时，ts_rank() 必须和 tsvector 同源
有人写 ORDER BY (SELECT ts_rank(tsv, q) FROM ...) DESC，结果排序错乱或报错。因为 ts_rank() 要求第一个参数是 tsvector，第二个是 tsquery，且两者语言配置必须一致；子查询若从另一张表取 tsv，但没同步传 to_tsquery('english', ...)，就会类型不匹配或权重归零。
- 排序字段必须和 WHERE 中的
tsvector来自同一列（如都用p.tsv） - 不要在 ORDER BY 里重复调用
to_tsvector()，否则既慢又无法利用索引统计信息 - 若需按多个字段混合排名，用
setweight()预加权，而不是靠子查询动态算
最易被忽略的一点：子查询返回的 tsvector 如果来自不同语言配置（比如一个用 'english'，另一个用 'zh_cn'），@@ 和 ts_rank() 全部静默失效——不报错，但永远返回 false 或 0。配置名必须字面一致，大小写敏感，且插件已安装启用。
