如何在Postgresql中加速复杂查询

如何加快以下查询的执行？仅检索37条记录就花费了65秒。伙计们，有什么解决办法吗？（我在x86_64-unknown-linux-gnu上使用PostgreSQL 9.1.6，由gcc（gcc）4.4.6 20120305（Red Hat 4.4.6-4）编译，64位） 以下是查询：

select cc.claim_id, 
cc.claim_date, 
CONCAT(cc.user_id, ' | ', uu.user_name) as user_name,
CONCAT(f_get_channel_id_by_territory_id(cc.territory_id), ' | ', f_get_channel_name(f_get_channel_id_by_territory_id(cc.territory_id))) AS channel_name,
f_get_cluster(cc.user_id) AS cluster_id,
ff.frontliner_name 
from t_trx_card_claim cc join t_mtr_user uu on uu.user_id = cc.user_id
left join t_mtr_outlet_frontliner ff on f_get_territory_id(ff.outlet_id) = cc.territory_id
where f_get_cluster(cc.user_id) = '36'

这是一个解释分析输出（）：

---

函数f_get_territory_id和f_get_cluster中可能存在严重问题-强烈建议不要在WHERE和FROM（连接谓词）子句中使用函数（如果使用函数索引，则除外/因此这些函数必须是不可变的）。

是否可以发布此查询的解释分析输出？我看到的潜在问题是where子句中函数的使用，因为postgres无法直接在索引中查找正确的值。-1因为您应该提供有关设置的一些信息：从

解释分析开始，表结构。。。这里的“postgresql”标签链接到一些好的提示：请参阅，以获取有关提供的信息的建议。对不起，伙计们，我对postgresql这方面是新手。在你提到之前，我甚至不知道解释和分析。我添加了解释分析。谢天谢地，大部分时间都花在最上面的嵌套循环左连接上，因为涉及的行数相当少，我认为该连接筛选器中使用的f_get_territory_id是罪魁祸首。f_get_集群位于一个仅需197毫秒的部分中，因此不存在任何问题。你能发布f_get_territory_id函数的代码吗？也许它可以被优化。
Nested Loop Left Join  (cost=0.00..83503.84 rows=646 width=47) (actual time=2000.830..65689.982 rows=37 loops=1)
  Join Filter: (f_get_territory_id(ff.outlet_id) = cc.territory_id)
  ->  Nested Loop  (cost=0.00..433.50 rows=7 width=35) (actual time=174.417..198.364 rows=37 loops=1)
        ->  Seq Scan on t_trx_card_claim cc  (cost=0.00..375.53 rows=7 width=21) (actual time=174.407..197.932 rows=37 loops=1)
              Filter: (f_get_cluster(user_id) = 36)
        ->  Index Scan using ix_user_8 on t_mtr_user uu  (cost=0.00..8.27 rows=1 width=22) (actual time=0.008..0.009 rows=1 loops=37)
              Index Cond: ((user_id)::text = (cc.user_id)::text)
  ->  Materialize  (cost=0.00..1811.51 rows=42701 width=21) (actual time=0.006..30.225 rows=42701 loops=37)
        ->  Seq Scan on t_mtr_outlet_frontliner ff  (cost=0.00..1347.01 rows=42701 width=21) (actual time=0.003..27.457 rows=42701 loops=1)
Total runtime: 65690.524 ms