小编bur*_*nsy的帖子

有没有办法索引以下查询？

SELECT run_id, MAX ( frame ) , MAX ( time ) FROM run.frames_stat GROUP BY run_id;

我尝试在frameand上创建排序（非复合）索引time，并在 上创建索引run_id，但查询规划器不使用它们。

杂项信息：

• 不幸的是（出于我不会进入的原因）我无法更改查询
• 该frames_stat表有 4200 万行
• 表格不变（不会发生进一步的插入/删除）
• 查询总是很慢，只是变慢了，因为这个数据集比过去大。
• 表上没有索引
• 我们正在使用 Postgres 9.4
• 数据库的“work_mem”大小为 128MB（如果相关）。
• 硬件：130GB 内存，10 核至强

架构：

CREATE TABLE run.frame_stat (
  id bigint NOT NULL,
  run_id bigint NOT NULL,
  frame bigint NOT NULL,
  heap_size bigint NOT NULL,
  "time" timestamp without time zone NOT NULL,
  CONSTRAINT frame_stat_pkey PRIMARY KEY (id)
)

解释分析：

HashAggregate  (cost=1086240.000..1086242.800 …

我正在尝试为 Postgres 9.4 中的大型（1.2TB）静态表创建部分索引。

我的数据是完全静态的，所以我可以插入所有数据，然后创建所有索引。

在这个 1.2TB 的表中，我有一个名为的列run_id，可以清晰地划分数据。通过创建涵盖一系列run_ids 的索引，我们获得了出色的性能。下面是一个例子：

CREATE INDEX perception_run_frame_idx_run_266_thru_270
ON run.perception
(run_id, frame)
WHERE run_id >= 266 AND run_id <= 270;

这些部分索引为我们提供了所需的查询速度。不幸的是，每个部分索引的创建大约需要 70 分钟。

看起来我们的 CPU 有限（top进程显示为 100%）。
我可以做些什么来加快部分索引的创建？

系统规格：

• 18核至强
• 192GB 内存
• RAID 中的 12 个 SSD
• 自动吸尘器关闭
• 维护工作内存：64GB（太高？）

表规格：

• 大小：1.26 TB
• 行数：105.37亿
• 典型的索引大小：3.2GB（有 ~.5GB 的差异）

表定义：

CREATE TABLE run.perception(
id bigint NOT NULL,
run_id bigint NOT NULL,
frame bigint NOT NULL,
by character varying(45) NOT NULL,
by_anyone bigint NOT …