当SELECT
查询一个表l
时,没有联接且有数十亿行,通过将查询拆分为多个查询,并按以下方式拆分为不同的子集/范围来运行并发查询是一个好主意吗?索引列,例如整数主键id
?
还是Postgres内部已经这样做了,最终用户的速度没有明显提高?
我有两个用例:
获取总行数
获取id
s的列表
编辑-1:该查询在没有索引的列中有条件子句,而其中一列未索引
SELECT id
FROM l
WHERE indexed_column-1='A'
AND indexed_column-2='B'
AND not_indexed_column-1='C'
答案 0 :(得分:3)
Postgres自9.6版以来已内置并行化功能。 (当前版本已改进。)它比在大表上手动拆分gridspec
的效率要高得多。
您可以根据需要设置max_parallel_workers
的数量。
虽然您仅对SELECT
列感兴趣,但是在id
上建立索引(如果它是PK)可能会有所帮助,并满足index-only scan的先决条件。
答案 1 :(得分:3)
如果要计算行数,可以让PostgreSQL的内部查询并行化完成工作。它将更快,并且结果将保持一致。
如果要获取主键列表,则取决于查询的WHERE
条件。如果只选择几行,那么并行查询会很好。
如果要表的全部 id
个,PostgreSQL可能不选择并行计划,因为在两个表之间交换这么多值的代价是工作进程将超过并行化的优势。在这种情况下,按照您的设想,并行会话可能会更快。
答案 2 :(得分:0)
此4列复合索引可能会比使用并行性更快:
INDEX(indexed_column-1, indexed_column-2, -- first, in either order
not_indexed_column-1, id)