【问题标题】:Aggregate a single column in query with many columns将查询中的单个列与许多列聚合
【发布时间】:2013-04-07 17:56:57
【问题描述】:

当查询中有许多其他列时,是否有适当的方法来聚合单个列?

我试过this answer 可行,但我的查询变得更加冗长。

我当前的查询如下所示:

SELECT t1.foo1, t1.foo2, t2.foo3, t2.foo4, string_agg(t3.aggregated_field, ', ')
FROM tbl1 t1
LEFT JOIN tbl2 t2 ON t1.id = t2.fkeyid
LEFT JOIN tbl3 t3 ON t2.id = t3.fkeyid
GROUP BY t1.foo1, t1.foo2, t2.foo3, t2.foo4, t2.foo5, t2.foo6
ORDER BY t2.foo5, t2.foo6

查询有更多的字段和LEFT JOINs,重要的是所有这些字段都有1对1或1对0的关系,除了我要聚合的一个1对n的字段,用@987654324表示@ 在上面的伪查询中。

当我使用聚合函数时,SELECTORDER BY 中列出的所有字段必须是聚合的,或者是 GROUP BY 子句的一部分。这使我的查询方式比现在更详细。

即假设foo1是一个主键,当这个字段重复时,除了aggregated_field之外的所有其他字段也是相等的。我希望这些重复的行作为带有聚合字段值的单行结果。 (基本上是一个带有聚合列的select distinct

有没有更好的方法来做到这一点(不必将所有其他字段放在GROUP BY 中)或者我应该只在我的后端迭代结果集,为获取这个 1 到 n 的每一行执行一个查询关系?


服务器运行的是 PostgreSQL 9.1.9,更具体地说:

x86_64-unknown-linux-gnu 上的 PostgreSQL 9.1.9,由 gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54) 编译,64 位

【问题讨论】:

  • 为什么开发人员披露他所询问的软件版本。为什么?在 SO 上,这是一个痛苦的群众现象。这就像原本非常聪明的人一旦提出问题就会立即变成傻瓜。提供您的软件版本和您的问题。 这应该不言而喻。
  • @ErwinBrandstetter 我的错,版本是 9.0+,我将连接到服务器的网络,以便在添加问题之前检查确切的版本。
  • @ErwinBrandstetter 已更新。
  • 谢谢。我的评论是不断积累的挫败感的结果。应该是那么明显。然而,很多人都没有想到。甚至是名声大噪的人。顺便说一句,9.1 - 你在那里很幸运。我的回答应该对你有用。
  • @ErwinBrandstetter 是的,我明白了。尽管string_agg 的使用隐含地使它成为pgsql9+,但我应该比小版本有重大变化更清楚,而且我承认我不事先检查版本是我的懒惰。浏览答案非常有意义,当我有时间应用和测试它时,我会在一小时左右提供反馈。 =]

标签: sql postgresql aggregate-functions


【解决方案1】:

简单查询

使用 PostgreSQL 9.1 或更高版本,这可以简单得多。正如这个密切相关的答案中所解释的那样:

GROUP BY 一个表的主键就足够了。自:

foo1 是主键

.. 您可以将示例简化为:

SELECT foo1, foo2, foo3, foo4, foo5, foo6, string_agg(aggregated_field, ', ')
FROM   tbl1
GROUP  BY 1
ORDER  BY foo7, foo8;  -- have to be spelled out, since not in select list!

多表查询

但是,既然你有:

更多字段和 LEFT JOIN,重要的是所有这些字段都具有 1 对 1 或 1 对 0 的关系,除了我要聚合的 1 对 n 字段

.. 先聚合,后加入应该更快更简单:

SELECT t1.foo1, t1.foo2, ...
     , t2.bar1, t2.bar2, ...
     , a.aggregated_col 
FROM   tbl1 t1
LEFT   JOIN tbl2 t2 ON ...
...
LEFT   JOIN (
   SELECT some_id, string_agg(agg_col, ', ') AS aggregated_col
   FROM   agg_tbl a ON ...
   GROUP  BY some_id
   ) a ON a.some_id = ?.some_id
ORDER  BY ...

这样,您的大部分查询根本不需要聚合。

我最近在 SQL Fiddle 中提供了一个测试用例来证明这个相关答案中的观点:

既然你指的是this related answer:不,DISTINCT 在这种情况下根本没有帮助。

【讨论】:

  • 是的,我注意到几个小时前DISTINCT 在这种情况下无济于事。我回家后会检查你的答案。 =]
  • 据我了解,子查询将隐式创建一个临时表,其中包含连接前整个表的聚合。在这种情况下,如果我在子查询中放置 WHERE 子句,我可以对其进行一些优化,对吗?这看起来是最好的方法,我会根据我的需要进行调整。谢谢。
  • @FabrícioMatté:WHERE 子句可能很有用,尤其是当您有与其对应的索引时。但是,根据整个查询,Postgres 查询计划器可能会使用不同的计划,无论它期望最快(这就是正确配置的planner cost constants)。它不一定是“临时表”(具体化步骤)。使用EXPLAIN ANALYZE 进行测试以获取详细信息。
【解决方案2】:

如果主要问题是计算字段 (foox),那么这会有所帮助:

SELECT foo1, foo2, foo3, foo4, foo5, foo6, string_agg(aggregated_field, ', ')
FROM tbl1
GROUP BY 1, 2, 3, 4, 5, 6
ORDER BY 5, 6

1, 2... 是按它们在选择列表中出现的顺序排列的字段。

【讨论】:

  • 虽然不理想,但我想这会减少我问的冗长。今天中午会做更多的研究。
  • 效果很好,请注意:foo7foo8 不能以这种方式枚举,除非它们也在 SELECT 列表中。
  • @FabrícioMatté 是的,我只是复制并猜测它们在真正的选择列表中。
  • 我会保留 +1,因为它对我有用,但是当您在选择中有 30 个字段并且在 ORDER BY 中有更多字段时,这不是很容易维护。 =]
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-01-01
  • 2013-10-24
  • 1970-01-01
相关资源
最近更新 更多