并行工作者未与 BRIN 索引一起使用答案

【问题标题】：Parallel Workers Not Being Used With BRIN Index并行工作者未与 BRIN 索引一起使用
【发布时间】：2020-08-14 00:30:15
【问题描述】：

我们目前正在运行一个查询，该查询执行一个非常简单的连接和分组，以获取行数，最后是一个联合。

(select
table_p."name",
table_p.id,
count(table.id),
sum(table.views)
    from table
        inner join table_p on table_p.id = table.pageid
        where table.date BETWEEN '2020-03-01' AND '2020-03-31'
            group by table_p.id
            order by table_p.id)
union all
(select
table_p."name",
table_p.id,
count(table.id),
sum(table.views)
    from table
        inner join table_p on table_p.id = table.pageid
        where table.date BETWEEN '2020-02-01' AND '2020-02-29'
            group by table_p.id
            order by table_p.id)
union all ....

我们决定使用 BRIN 索引，因为我们的表有 3.6 亿条记录。如果需要，我们确实可以选择使用 B-Tree。

现在，由于某种原因，我们在解释分析中看到 BRIN 指数已将“并行感知”设置为 false，并且在输出的计划中列出了两名工人？此外，在分解我们查询的数量时，我们看到了线性性能，即 5 秒内一个月，20 秒内四个月。我假设这意味着我们正在异步查询而不是并行查询。

是否有人对我们可能遗漏的内容有任何想法，以便在可能的情况下进行并行查询？ BRIN 不能与 Parallel Worker 一起使用吗？

编辑：这是“table”上的 BRIN 索引：

CREATE INDEX table_brin_idx
    ON table USING brin
    (date, teamid, id, pageid, devicetypeid, makeid, modelid)
    TABLESPACE pg_default;

我的 postgres 版本是 PostgreSQL 11.6，由 Visual C++ build 1800 编译，64 位

Here's a link to the explain analyze that's too big to post here.

【问题讨论】：

哪个表有 BRIN 索引，在哪些列上？什么版本的PG？包括 EXPLAIN ANALYZE 输出。
@AdamKG 我已在帖子底部添加了您要求的内容。
JSON 可能很适合机器阅读，但由于 EXPLAIN 输出对于人类来说大多难以辨认，比如我。请显示文本格式。但我可以看出您的计划实际上是使用并行工作器，请注意"Workers Launched": 2,
该查询为每个 SELECT 中的每个 Gather Merge 节点使用 2 个 worker，但在顶层使用非并行 Append 节点来组合 UNION ALL，因此每个月都按顺序查询，每月花费约 4.5 秒。我不确定为什么它不使用 ParallelAppend。查看 EXPLAIN 是否随 set effictive_io_concurrency = 10（默认为 1）、set max_parallel_workers_per_gather = 8（默认为 2）或两者同时更改。请注意，如果您受 IO 限制，则规划器使用常规 Append 可能是正确的，并且您实际上不会从 ParallelAppend 查询计划中获得更快的结果。
@AdamKG 提高最大收集者确实让 postgres 使用 4 个工作人员而不是 2 个工作人员。在查询所有 12 个月时，速度稍微加快了一些。在 Azure 上检查我们的使用情况时，我们不受 IO 限制。甚至没有受到 CPU 使用率的限制。

标签： postgresql indexing database-performance

【解决方案1】：

来自 PostgreSQL 文档的信息：目前，并行索引扫描仅支持 btree 索引。来源：https://www.postgresql.org/docs/11/parallel-plans.html#PARALLEL-SCANS

【讨论】：