【问题标题】:Average over a period of time is very slow一段时间内的平均速度很慢
【发布时间】:2019-08-21 09:51:46
【问题描述】:

我正在尝试使用 postgresql 在一段时间内计算多个平均值(每个 id 一个)。

我有一个有效的查询,但它非常非常慢。 (在我的笔记本电脑上 3 分钟,在服务器上 30 秒..)

我要做的是计算过去 X 天的平均值。可能存在日期间隔(对于没有数据的周六和周日),但我仍然需要最后一个 X。所以例如 1 个月将是 20 天,等等。

为了做到这一点,我一直在使用row_number() OVER (PARTITION BY item_id ORDER BY tdate DESC) 并且只选择BETWEEN 0 AND X(X 是我需要的最大日期数)

我的完整查询是:

SELECT x.item_id AS id,avg(x.value) AS result FROM 

(SELECT il.item_id, il.value,  row_number() OVER (PARTITION BY 
il.item_id  ORDER BY il.tdate DESC) rn 

FROM item_prices il) x

WHERE x.rn BETWEEN 0 AND 50 GROUP BY x.item_id order by x.item_id ASC;

正如我所说,我的问题是它非常慢。我怀疑 PSQL 正在为每个 id 重新计算 SELECT il.item_id, il.value, row_number() OVER (PARTITION BY il.item_id ORDER BY il.tdate DESC,这就是它如此缓慢的原因。

我一直在阅读有关平均值的文章并尝试了一些东西 (this),但没有成功。

有人知道如何使查询更快吗?

我的桌子是这样的:

ID,item_id,value,tdate

解释:

GroupAggregate  (cost=7707688.82..8934895.66 rows=36453 width=36)
  Group Key: x.item_id
   ->  Subquery Scan on x  (cost=7707688.82..8933564.38 rows=175125 width=14)
    Filter: ((x.rn >= 1) AND (x.rn <= 50))
    ->  WindowAgg  (cost=7707688.82..8408189.14 rows=35025016 width=26)
          ->  Sort  (cost=7707688.82..7795251.36 rows=35025016 width=18)
                Sort Key: il.item_id, il.tdate DESC
                ->  Seq Scan on item_prices il  (cost=0.00..1163862.16 rows=35025016 width=18)

【问题讨论】:

  • 我不明白。您想要最后 n 天吗?还是您想要每个 item_id 的最后 n 行?

标签: sql postgresql average


【解决方案1】:

我要做的是计算过去 X 天的平均值。

这表明:

SELECT ip.item_id AS id, avg(x.value) AS result
FROM item_prices ip
WHERE ip.tdate <= current_date AND
      ip.tdate > current_date - X * interval '1 day'
GROUP BY ip.item_id;

不过,我看不出您的实际查询与您提出的问题有什么关系。

【讨论】:

  • 因为我需要最后一个“日期”而不是天数,所以这是我的思考过程,它也不是从当前日期开始,而是从 max(date) 开始,但这不会改变您查询的有效性另一方面,如果我需要 50 个日期,但当 50 * interval '1 day' 等于 40 个日期时,问题就会出现,因为在周末没有日期,没有 X 或 Y 假期的数据等。这就是为什么我解释说可能有日期差距,但我仍然需要静态数量的“日期” - 我将尝试使用 max(tdate) 进行查询,因为我不确定间隔的行为是否与我认为的完全一致。
【解决方案2】:

您可以尝试将以下索引添加到item_prices 表中:

CREATE INDEX idx ON item_prices (item_id, tdate, value);

这可能会加快ROW_NUMBER 中的分区速度,从而提高内部查询的性能。关于求平均值,无法避免触及每个item_id 范围内的每个值,因此可能没有太多其他可以做的事情。

其实还有另外一个小优化。您可以从内部查询中删除 ORDER BY 子句,这没有任何作用(甚至不会“粘贴”):

SELECT
    x.item_id AS id,
    AVG(x.value) AS result
FROM 
(
    SELECT il.item_id, il.value,
        ROW_NUMBER() OVER (PARTITION BY il.item_id ORDER BY il.tdate DESC) rn 
    FROM item_prices il
) x
WHERE
    x.rn BETWEEN 1 AND 50     -- row number starts at 1, not 0
GROUP BY
    x.item_id
ORDER BY
    x.item_id;

【讨论】:

  • 所以一般来说,对于这样的计算(平均值),只检索值并在应用程序中计算它们会更好吗?因为它快 40-50 倍?我在理解如何如此缓慢并且没有任何解决方法更好的做法时遇到问题。
  • 您是否尝试过我回答中的建议?我认为它至少应该提供一些的改进。不...不要在您的应用程序中进行这些聚合;这可能会表现得更糟。
  • 索引已经在那里了.. :( 至于我的订单,我无法完全理解如何删除它,因为它有助于在最新日期之前对其进行排序,以便它可以如果删除,则获得正确的 50 最后日期,但我可能会误解。此外,我的主键是 tdate+item_id 上的合成,这会减慢任何速度吗?
  • 子查询中的ORDER BY 甚至没有意义,因为该顺序不会持续进入外部查询。
  • 有和没有 order by 不会产生相同的结果,但我不知道为什么,因为你说订单不会持续存在。我会尝试手动计算,看看发生了什么
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2014-09-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-02-08
  • 1970-01-01
  • 2012-06-25
相关资源
最近更新 更多