联合会比零件总和还贵。在postgres中可能会出现选择的惰性联合吗？

Question

我想在以下位置执行快速文本搜索：

1. 首选精确匹配查询文本（第一顺序优先级）
2. 匹配的查询文本为第二个前缀（第一优先级）
3. 三元组匹配是第三优先级。

类似的东西：

select *
from description
where 
  term ilike %% 'query'
order by
  term ilike 'query'  -- prefer exact match
  term ilike 'query%'  -- prefer starts with
-- LENGTH(term)     -- fill with fuzzy trigram match, shortest first
limit 10

但是，上述操作相当缓慢，因此我尝试了：

-- select * FROM (

  select *       -- 100 ms when run alone
  FROM  description d
  where term ilike 'hyp'
UNION
  select * from (  -- 100 ms when run alone, returns 1000 rows if no limit 
      select * 
      FROM  snomed_ct.description d
      where  d.term ilike 'hyp%'
  ) as x
UNION
  select *   -- 200ms seconds when run alone (with limit 10)
  FROM  description d
  where   d.term % 'hyp'
-- ) as d
limit 10

...希望得到有用的东西。但是，此查询似乎比其总和要长得多-1.6秒。

前两个选择非常快。 第三个添加到并集时非常慢，但如果限制为10个结果，则相当快。

全部费用与第三次选择的费用大致相同（无限制）：

      select *  
      FROM  description d
      where   d.term % 'hyp'

我希望实现是这样的：

selects = [select1_iterator, select2_iterator, select3_iterator, ]
iter = chain(selects) # pick from 1st iterator, then second, then 3rd
iter = duplicated(selects) # skip duplicates
iter = limit(selects, 10)  # pick 1st 10

...在select1_iterator用尽之前，我们将不关注select2_iterator等。但是全部费用与无限子查询的总和相同。

问题：

1. 这是预期的吗？我意识到限制适用于整个工会（这是意图）。但是，难道不应该将联合函数作为接受并返回行迭代器而不是表的对象吗？ （请参阅“说明”屏幕截图，“ Aggregate”本可以使用10个，但它会获得8000行）。

2. 有没有办法使postgres像上面的伪代码中那样逐步起作用？ -仅按照指定的顺序执行所需的操作？ （我知道工会不保证订购）。