子查询本身不加速tsvector和to_tsquery，但能规避全文检索低效写法：提前计算tsvector、下推过滤条件、缩小结果集；配合物化CTE、生成列或GIN索引可显著提升性能。

tsvector 和 to_tsquery 本身不靠子查询提速，但子查询能帮你**规避全文检索的常见低效写法**——比如在 WHERE 中反复调用 to_tsquery 或对大表逐行做 @@ 判断。真正起效的是把计算提前、把过滤下推、把结果集缩小。

用子查询预计算 tsvector 并物化中间结果

全文检索慢，常因每次查询都重新解析 to_tsvector('english', content)，尤其当 content 是 TEXT 字段且未建 GIN 索引时。子查询可把转换逻辑“拉出来”，配合 MATERIALIZED CTE 或临时表固化结果。

• 对频繁检索的字段，优先在表上加 GENERATED 列或单独建 tsvector 列并索引，而非每次在子查询里算
• 若必须动态生成，用 WITH 子句把 tsvector 计算和过滤分离，避免在主查询 WHERE 中重复调用函数
• 示例（避免在 WHERE 中直接 to_tsvector(...) @@ to_tsquery(...)）：

  WITH ranked_docs AS (
    SELECT id, title, content,
           to_tsvector('english', coalesce(title, '') || ' ' || coalesce(content, '')) AS doc_tsv
    FROM articles
    WHERE published_at >= '2025-01-01'
  )
  SELECT id, title
  FROM ranked_docs
  WHERE doc_tsv @@ to_tsquery('english', 'database & performance');

用子查询替代 NOT IN 实现负向全文过滤

NOT IN (SELECT ...) 遇到 NULL 会整个失效，而全文检索中常需“排除含某词的文档”。直接写 NOT (col @@ query) 是最安全的，但如果逻辑复杂（比如排除多个关键词组合），子查询配合 EXISTS 更可控、更易优化。

• NOT IN 在子查询返回 NULL 时结果为空，这是硬伤，别碰
• 用 NOT EXISTS 子查询替代，让优化器有机会用反向索引扫描（如果字段有 GIN 索引）
• 示例：

  SELECT id, title
  FROM articles a
  WHERE NOT EXISTS (
    SELECT 1 FROM articles b
    WHERE b.id = a.id
      AND to_tsvector('english', b.content) @@ to_tsquery('english', 'spam | advertisement')
  );

子查询 + LATERAL 实现多关键词分层打分

想按不同字段（title vs content）赋予不同权重，又不想写冗长的 ts_rank 表达式？LATERAL 子查询能让你把评分逻辑封装起来，且只对已过滤后的行计算，避免全表打分开销。

• LATERAL 允许子查询引用外部行，适合做 per-row 的全文评分、高亮或关键词提取
• 务必确保外层已有强过滤条件（如时间范围、状态字段），否则 LATERAL 会放大计算量
• 示例：

  SELECT a.id, a.title, r.rank
  FROM articles a
  CROSS JOIN LATERAL (
    SELECT ts_rank(
      to_tsvector('english', a.title || ' ' || a.content),
      to_tsquery('english', 'optimization')
    ) AS rank
  ) r
  WHERE a.status = 'published'
    AND r.rank > 0.1;

关键点不在子查询本身有多快，而在于它帮你把全文检索的「计算」和「过滤」解耦——让 to_tsvector 不重复执行、让 NOT 逻辑不被 NULL 拖垮、让 ts_rank 只算该算的行。这些地方一松动，EXPLAIN ANALYZE 里就能看到 Bitmap Heap Scan 替代 Seq Scan、Index Cond 出现在计划顶部。