相关疑难解决方法(0)

2020-08-04 更新：

由于显然仍在定期查看此答案，因此我想提供有关情况的最新信息。我们目前正在使用带有表分区的 PG 11，timestamp并且可以轻松处理表中的数十亿行。仅索引扫描可以挽救生命，没有它就不可能。

使用 PostgreSQL 9.2，我在相对较大的表（200 多万行）上进行慢速查询时遇到问题。我没有尝试任何疯狂的事情，只是增加了历史价值。下面是查询和查询计划输出。

我的表布局：

                                   Table "public.energy_energyentry"
  Column   |           Type           |                            Modifiers
-----------+--------------------------+-----------------------------------------------------------------
 id        | integer                  | not null default nextval('energy_energyentry_id_seq'::regclass)
 prop_id   | integer                  | not null
 timestamp | timestamp with time zone | not null
 value     | double precision         | not null
Indexes:
    "energy_energyentry_pkey" PRIMARY KEY, btree (id)
    "energy_energyentry_prop_id" btree (prop_id)
    "energy_energyentry_prop_id_timestamp_idx" btree (prop_id, "timestamp")
Foreign-key constraints:
    "energy_energyentry_prop_id_fkey" FOREIGN KEY (prop_id) REFERENCES gateway_peripheralproperty(id) DEFERRABLE INITIALLY DEFERRED

数据范围从2012-01-01至今，新数据不断增加。prop_id外键中大约有 2.2k 个不同的值，均匀分布。

我注意到行估计值相差不远，但成本估计值似乎大了 …

如何用和解决gaps-and-islands的孤岛部分。我现在已经看过几次了，我想知道是否有人可以解释一下，dense_rank()row_number()

让我们使用这样的东西作为示例数据（示例使用 PostgreSQL），

CREATE TABLE foo
AS
  SELECT x AS id, trunc(random()*3+1) AS x
  FROM generate_series(1,50)
    AS t(x);

这应该产生这样的东西。

 id | x 
----+---
  1 | 3
  2 | 1
  3 | 3
  4 | 3
  5 | 3
  6 | 2
  7 | 3
  8 | 2
  9 | 1
 10 | 3
...

我们想要的是这样的...... （z我们可以使用的价值在哪里GROUP BY）

 id | x | grp
----+------
  1 | 3 | z
  2 | …

我需要在滚动总和计算上设置一个下限。例如，与

PKID    NumValue    GroupID
----------------------------
1       -1          1
2       -2          1
3       5           1
4       -7          1
5       1           2

我想拥有：

PKID   RollingSum    GroupID
----------------------------- ## Explanation: 
1      0             1        ## 0 - 1 < 0  => 0
2      0             1        ## 0 - 2 < 0  => 0
3      5             1        ## 0 + 5 > 0  => 5
4      0             1        ## 5 - 7 < 0  => 0

当添加一个负数将导致总和为负时，将激活限制以将结果设置为零。后续的加法应该基于这个调整后的值，而不是原来的滚动总和。

应该使用加法来达到预期的结果。如果第四个数字从 -7 变为 -3，则第四个结果应该是 2 而不是 0

如果可以提供单个金额而不是几个滚动数字，那也是可以接受的。我可以使用存储过程来实现非负加法，但这太低级了。 …