2014-01-10 55 views
0

我有以下有点复杂SELECT声明有多个连接,一组通过,并通过命令:优化复杂的Postgres SQL SELECT语句吗?

SELECT 
    COUNT(*) AS count_all, 
    "response_variables"."id", 
    "response_variables"."var_name" AS "response_variables_id_response_variables_var_name" 
FROM "response_variables" 
    INNER JOIN "responses" ON "responses"."id" = "response_variables"."response_id" 
    INNER JOIN "questions" ON "questions"."id" = "responses"."question_id" 
WHERE "questions"."key" = 'rbmmpmvs' 
GROUP BY "response_variables"."id", "response_variables"."var_name" 
ORDER BY "response_variables"."var_name" ASC; 

下面是对运行EXPLAIN ANALYZE的输出:

GroupAggregate (cost=720.80..723.20 rows=120 width=9) (actual time=277.127..285.953 rows=15265 loops=1) 
    -> Sort (cost=720.80..721.10 rows=120 width=9) (actual time=277.120..281.391 rows=15265 loops=1) 
     Sort Key: response_variables.var_name, response_variables.id 
     Sort Method: external merge Disk: 288kB 
     -> Nested Loop (cost=0.00..716.66 rows=120 width=9) (actual time=0.064..21.795 rows=15265 loops=1) 
       -> Nested Loop (cost=0.00..657.78 rows=128 width=4) (actual time=0.050..7.919 rows=3042 loops=1) 
        -> Index Scan using index_questions_on_key on questions (cost=0.00..8.27 rows=1 width=4) (actual time=0.032..0.033 rows=1 loops=1) 
          Index Cond: ((key)::text = 'rbmmpmvs'::text) 
        -> Index Scan using index_responses_on_question_id on responses (cost=0.00..646.69 rows=282 width=8) (actual time=0.016..7.326 rows=3042 loops=1) 
          Index Cond: (question_id = questions.id) 
       -> Index Scan using index_response_variables_on_response_id on response_variables (cost=0.00..0.42 rows=4 width=13) (actual time=0.002..0.003 rows=5 loops=3042) 
        Index Cond: (response_id = responses.id) 
Total runtime: 288.766 ms 
(13 rows) 

我有一个不同点数的索引数量,但不知道从哪里开始优化通话(或者如果可能的话)。

+2

您目前的work_mem设置是什么?看起来你可以使用额外的东西:SET work_mem TO'100MB'; –

+1

+1 @FrankHeikens甚至更多,以获得HashAggregate计划。 –

回答

0

where子句中的条件适用于最内部连接的表。这很糟糕,因为必须在之前完成所有加入,发现问题行的匹配或不匹配。

相反,列出问题表第一,反转表顺序:

SELECT 
    COUNT(*) AS count_all, 
    response_variables.id, 
    response_variables.var_name AS response_variables_id_response_variables_var_name 
FROM questions 
JOIN responses ON questions.id = responses.question_id 
JOIN response_variables ON responses.id = response_variables.response_id 
WHERE questions.key = 'rbmmpmvs' 
GROUP BY response_variables.id, response_variables.var_name 
ORDER BY response_variables.var_name 

只要有上question(key)的指标,ID列,这应该表现良好。

我还删除了导致代码噪声的所有不必要的双引号。

+0

对表格进行重新排序在Postgres中将没有什么区别,因为规划师会尽其所能地尝试每个顺序的连接,除非有一个(可配置的)大量的连接。 –

0

试试这个:

SELECT 
    COUNT(*) AS count_all, 
    response_variables.id, 
    response_variables.var_name AS response_variables_id_response_variables_var_name 
FROM questions 
WHERE 1=1 
AND EXISTS (Select 1 from responses where responses.id = questions.id) 
AND EXISTS (Select 1 from response_variables where response_variables.id = questions.id) 
AND questions.key = 'rbmmpmvs' 
GROUP BY response_variables.id, response_variables.var_name 
ORDER BY response_variables.var_name 

而且,您的查询是做一个基于磁盘的外部合并,这可能会非常缓慢,而且时间大约90%在排序(259.596毫秒)度过的。

正如在解释计划中所说的,大约288kb的数据被写入磁盘,因为它的数据无法放入work_mem中。为事务争取本地work_mem将强制规划者使用内存中的快速排序,这应该比外部合并排序快得多。