2013-09-27 128 views
0

我注意到以下查询在我的代码中,并希望检查是否可以优化。优化Postgres查询

UPDATE table as T1 SET C1=? 
    FROM 
    (SELECT C2, C3, C4 
     FROM table 
     WHERE C1=? and current_timestamp >= C5 
     ORDER BY C5 limit ? FOR UPDATE 
    ) AS T2 
WHERE T1.C2 = T2.C2 AND T1.C3 = T2.C3 AND T1.C4 = T2.C4 
RETURNING *; 

指数C2,C3

上C5分配

表:

C1,C2,C3 - VARCHAR
C4,C5 - 时间戳

+4

不可能用一个非常神秘的查询来回答。使用解释分析来计算postgresql花费的时间。如果您需要解释分析输出的帮助,请将其插入到您的问题中。 – Eelke

+1

无法保证子查询仅为每个目标行返回一个(或零)行。请在尝试优化性能之前先修复您的逻辑。 (如果这是你的意图,那么'order by .. limit 1'是将子查询限制为一行的可怕方法) – joop

回答

0

过早的优化是数据库中所有邪恶的根源。设计时要考虑到理智,然后在出现问题时向我们展示。我不会回答这个问题,而是解释为什么它不能得到回答。

SQL是一种声明式语言,您可以在其中向数据库系统提供某种类似数学公式的数据,并且它会计算出如何以最佳方式运行它。那么,从技术上来说,查询的一个数学公式,但数学镜像SQL和SQL近似称为关系代数的另一个数学领域。

实际的优化过程在很大程度上取决于读写模式以及规划器知识的局限性。除非你有一个实际的瓶颈,否则没有办法评估一个查询相对于另一个查询的性能,除非你在你的例子中没有提供某些东西(NOT EXISTS往往是昂贵的,而且一个往往会更好地将它写成外部联接并且针对内部联合的情况进行筛选,而不是作为一个反联盟,可能这将在未来得到解决)。即使在那里,也有很多情况下,反加入不会产生重大影响,并且绩效的提升可能不值得担忧。

所以重点是你需要等到你有一个实际的问题之前优化查询。然而,优化存储是非常不同的。