Sql 在有时间间隔的CTE上慢速左连接

我正在尝试调试PostgreSQL中的一个查询，该查询是我构建的，以任意时间间隔在时间段中存储市场数据。以下是我的表定义：

CREATE TABLE historical_ohlcv (
  exchange_symbol TEXT                     NOT NULL,
  symbol_id       TEXT                     NOT NULL,
  kafka_key       TEXT                     NOT NULL,
  open            NUMERIC,
  high            NUMERIC,
  low             NUMERIC,
  close           NUMERIC,
  volume          NUMERIC,
  time_open       TIMESTAMP WITH TIME ZONE NOT NULL,
  time_close      TIMESTAMP WITH TIME ZONE,
  CONSTRAINT historical_ohlcv_pkey
  PRIMARY KEY (exchange_symbol, symbol_id, time_open)
);

CREATE INDEX symbol_id_idx
  ON historical_ohlcv (symbol_id);

CREATE INDEX open_close_symbol_id
  ON historical_ohlcv (time_open, time_close, exchange_symbol, symbol_id);

CREATE INDEX time_open_idx
  ON historical_ohlcv (time_open);

CREATE INDEX time_close_idx
  ON historical_ohlcv (time_close);

该表目前约有2500万行。我的查询作为一个1小时的示例，但可能是5分钟、10分钟、2天等

EXPLAIN ANALYZE WITH vals AS (
    SELECT
      NOW() - '5 months' :: INTERVAL AS frame_start,
      NOW() AS frame_end,
      INTERVAL '1 hour'        AS t_interval
)
  , grid AS (
      SELECT
        start_time,
        lead(start_time, 1)
        OVER (
          ORDER BY start_time ) AS end_time
      FROM (
             SELECT
               generate_series(frame_start, frame_end,
                               t_interval) AS start_time,
               frame_end
             FROM vals
           ) AS x
  )
SELECT max(high)
FROM grid g
  LEFT JOIN historical_ohlcv ohlcv ON ohlcv.time_open >= g.start_time
WHERE exchange_symbol = 'BINANCE'
AND symbol_id = 'ETHBTC'
GROUP BY start_time;

WHERE子句可以是表中的任何有效值

这项技术的灵感来自：

其思想是创建一个公共表，并将数据与该表左键连接，以指示存储桶中的内容。这个查询真的很慢！目前需要15秒。根据查询计划器，我们有一个非常昂贵的嵌套循环：

QUERY PLAN
HashAggregate  (cost=2758432.05..2758434.05 rows=200 width=40) (actual time=16023.713..16023.817 rows=542 loops=1)
  Group Key: g.start_time
  CTE vals
    ->  Result  (cost=0.00..0.02 rows=1 width=32) (actual time=0.005..0.005 rows=1 loops=1)
  CTE grid
    ->  WindowAgg  (cost=64.86..82.36 rows=1000 width=16) (actual time=2.986..9.594 rows=3625 loops=1)
          ->  Sort  (cost=64.86..67.36 rows=1000 width=8) (actual time=2.981..4.014 rows=3625 loops=1)
                Sort Key: x.start_time
                Sort Method: quicksort  Memory: 266kB
                ->  Subquery Scan on x  (cost=0.00..15.03 rows=1000 width=8) (actual time=0.014..1.991 rows=3625 loops=1)
                      ->  ProjectSet  (cost=0.00..5.03 rows=1000 width=16) (actual time=0.013..1.048 rows=3625 loops=1)
                            ->  CTE Scan on vals  (cost=0.00..0.02 rows=1 width=32) (actual time=0.008..0.009 rows=1 loops=1)
  ->  Nested Loop  (cost=0.56..2694021.34 rows=12865667 width=14) (actual time=7051.730..16015.873 rows=31978 loops=1)
        ->  CTE Scan on grid g  (cost=0.00..20.00 rows=1000 width=16) (actual time=2.988..11.635 rows=3625 loops=1)
        ->  Index Scan using historical_ohlcv_pkey on historical_ohlcv ohlcv  (cost=0.56..2565.34 rows=12866 width=22) (actual time=3.712..4.413 rows=9 loops=3625)
              Index Cond: ((exchange_symbol = 'BINANCE'::text) AND (symbol_id = 'ETHBTC'::text) AND (time_open >= g.start_time))
              Filter: (time_close < g.end_time)
              Rows Removed by Filter: 15502
Planning time: 0.568 ms
Execution time: 16023.979 ms

查询计划
HashAggregate（成本=2758432.05..2758434.05行=200宽度=40）（实际时间=16023.713..16023.817行=542个循环=1）
组键：g.开始时间
CTE VAL
->结果（成本=0.00..0.02行=1宽度=32）（实际时间=0.005..0.005行=1圈=1）
CTE网格
->WindowAgg（成本=64.86..82.36行=1000宽度=16）（实际时间=2.986..9.594行=3625个循环=1）
->排序（成本=64.86..67.36行=1000宽度=8）（实际时间=2.981..4.014行=3625循环=1）
排序键：x.开始时间
排序方法：快速排序内存：266kB
->x上的子查询扫描（成本=0.00..15.03行=1000宽度=8）（实际时间=0.014..1.991行=3625循环=1）
->项目集（成本=0.00..5.03行=1000宽度=16）（实际时间=0.013..1.048行=3625圈=1）
->VAL上的CTE扫描（成本=0.00..0.02行=1宽度=32）（实际时间=0.008..0.009行=1循环=1）
->嵌套循环（成本=0.56..2694021.34行=12865667宽度=14）（实际时间=7051.730..16015.873行=31978个循环=1）
->网格g上的CTE扫描（成本=0.00..20.00行=1000宽度=16）（实际时间=2.988..11.635行=3625圈=1）
->在历史ohlcv ohlcv上使用历史ohlcv pkey进行索引扫描（成本=0.56..2565.34行=12866宽度=22）（实际时间=3.712..4.413行=9个循环=3625）
索引条件：（（exchange_symbol='BINANCE'：：text）和（symbol_id='ETHBTC'：：text）和（time_open>=g.start_time））
过滤器：（时间\关闭

我猜这句话很有用：

LEFT JOIN historical_ohlcv ohlcv ON ohlcv.time_open >= g.start_time
                                AND ohlcv.time_close < g.end_time

左连接历史\u ohlcv ohlcv ohlcv ON ohlcv.time\u open>=g.start\u time
和ohlcv.time\u close

但我不确定如何以另一种方式实现这一点

如果这是属于dba.SE的，请向我们道歉。我读了FAQ，这对那个网站来说似乎太基本了，所以我把它贴在这里

按要求编辑：

从历史ohlcv t表采样系统（0.1）中选择平均值（pg列大小（t））返回107.632

对于
exchange\u symbol
，有3个唯一值，对于
symbol\u id
有~400个唯一值

PostgreSQL版本：x86_64-pc-linux-gnu上的PostgreSQL 10.3（Ubuntu 10.3-1.pgdg16.04+1），由gcc（Ubuntu 5.4.0-6ubuntu1~16.04.9）5.4.0 20160609编译，64位

该表每天将增长约100万条记录，因此不完全是只读的。所有这些都是在本地完成的，我将尝试转向RDS或帮助管理硬件问题

相关：如果我想添加其他聚合，特别是“桶中第一个”、“桶中最后一个”、min、sum，我的索引策略会改变吗？
正确性优先：我怀疑您的查询中存在错误：

 LEFT JOIN historical_ohlcv ohlcv ON ohlcv.time_open >= g.start_time
                                 AND ohlcv.time_close < g.end_time

相关的：




虽然基础还不清楚，但很难谈论进一步的性能优化。我们需要更多的信息

WHERE
条件是可变的吗？

exchange\u symbol
和
symbol\u id
中有多少不同的值？

平均行大小？你得到什么：

SELECT avg(pg_column_size(t)) FROM historical_ohlcv t TABLESAMPLE SYSTEM (0.1);

表是只读的吗

假设您总是在
exchange\u symbol
和
symbol\u id
上进行筛选，并且值是可变的，您的表是只读的，或者autovacuum可以跟上写负载，因此我们希望只进行索引扫描，您最好在
上使用多列索引（exchange\u symbol，symbol\u id，time\u open，high DESC）
以支持此查询。按此顺序索引列。相关的：




根据数据分布和其他详细信息，
左连接横向
解决方案可能是另一种选择。相关的：





除此之外，您还可以解释一下，该计划显示了一些非常糟糕的估计值：




您使用的是当前版本的Postgres吗？您可能需要处理服务器配置，或者至少在相关列上设置更高的统计目标，并为大表设置更积极的自动真空设置。相关的：




是否需要直接使用to_TIMESTAMP（ohlcv.time_open/1000）和to_TIMESTAMP（ohlcv.time_close/1000）表达式将time_open和time_close存储为BIGINT而不是TIMESTAMP？我认为在连接条件中使用这些表达式可以防止使用索引。Hi@iqiώσηπππποποπεκⅤμποΓερ我来试一试。我这样做了，它稍微提高了性能，但没有提高几个数量级：（你提供了很好的信息，但是在初学者中考虑：总是公开你的PASGREST版本。除了：这很复杂，足以适合DBA.SE。根据它，你可以在任何一个站点上发表这个帖子。谢谢你慷慨的回应。我已经编辑了我的问题，包括所要求的信息。”添加了一个新答案的链接，展示了
横向方法：
SELECT avg(pg_column_size(t)) FROM historical_ohlcv t TABLESAMPLE SYSTEM (0.1);