Postgres如何加快分区表上的select语句

Question

我正在寻找可以减少在我的数据仓库中运行选择语句的时间的方法。

我们目前正在运行 Postgres Enterprise 9.3.4.10，并打算在新的几个月内升级到 9.6。

有一个包含大约 9500 万行的 Fact 表，所有外键/id 列上都有 b-tree 索引。外键列是 smallint / integer 数据类型的混合。它们都是单列索引。还有一些度量，例如我们用于聚合的美元金额（sum / avg）。这些字段未编入索引。该表每天通过 Pentaho 使用 JDBC 插入/更新语句进行更新。该表还按activity_date_key 进行分区。

运行“从日期在 20160701 和 20160801 之间的表中选择总和（金额）”运行时间为 0.2 秒，但如果我将该时间范围增加到 20160101 和 20160801 之间，则运行时间会增加到 70 秒。 （日期字段是整数类型）。

我正在寻找一些关于我可以做些什么来减少这个时间的想法。可能有不同类型的索引？我读到 9.6 带有 BRIN 索引（块范围索引），但不确定这是否对我有帮助。是否有任何我可以安全调整的数据库配置参数？也许我的问题一般来说数据太多了？欢迎任何提示。如果您需要有关我的环境的更多信息，请告诉我。谢谢。

瑞恩

Answer 1

尝试调整你的 postgresql，在“postgresql.conf”中你会发现很多参数可以加速你的 postgresql，对于查询你有“work_mem”但要小心你拥有的连接数，pgtune 会让您了解如何设置参数，或阅读此article 以获得清晰的愿景。

Answer 2

以下是有关我的设置的一些附加信息以及到目前为止的一些问题的答案：

是的，activity_date_key 上有一个索引。总共有 16 个 b-tree 索引代表外键。

我确实想考虑 BRIN 索引，因为我们要升级到 9.6。是否有理由相信它与已在同一键上建立 b-tree 索引的分区表（按日期键）结合使用会很有用？

硬件配置 2CPU，每个 16 核 vendor_id：AuthenticAMD，cpu 系列：21，型号：2，型号名称：AMD Opteron(tm) 处理器 6378，cpu MHz：2400

netapp 存储阵列上的 192GB RAM SAS 磁盘

此服务器上还有 18 个其他数据库 - 非常过载。

解释（分析、缓冲）来自 fact_gc_activity 的 select count(*) 输出，其中 activity_date_key 介于 20160101 和 20160801 之间：

“聚合（成本=372804.89..372804.90 行=1 宽度=0）（实际时间=121284.418..121284.418 行=1 循环=1）”“缓冲区：共享命中=72295 读取=47564”“-> 追加（成本=0.00..347567.97 行=10094768 宽度=0）（实际时间=350.581..118020.641 行=10023451 循环=1）“”缓冲区：共享命中=72295 读取=47564“”-> 对 fact_gc_activity 进行 Seq 扫描（成本=0.00..0.00 行=1 宽度=0) (实际时间=0.001..0.001 行=0 循环=1)" " 过滤器: ((activity_date_key >= 20160101) AND (activity_date_key Index Only Scan using fact_gc_activity_201601_activity_date_key_idx on fact_gc_activity_201601 (cost=0.43..54563.87 rows=1748572 width=0) (actual time=350.577..5734.825 rows=1748572 loops=1)" " Index Cond: ((activity_101)0 ((activity_date101)0 () AND 2016 activity_date_key 仅索引扫描使用 fact_gc_activity_201602_activity_date_key_idx 在 fact_gc_activity_201602 上（成本=0.43..41641.89 行=1331873 宽度=0）（实际时间=183.811..3071 .842 rows=1331873 loops=1)" " Index Cond: ((activity_date_key >= 20160101) AND (activity_date_key Index Only Scan using fact_gc_activity_201603_activity_date_key_idx on fact_gc_activity_201603 (cost=0.43..45535.79 rows=1456368 width=0) (actual time=171.306..3069.430 rows=1456368 loops=1)" " Index Cond: ((activity_date01)0 ((activity_date101)0 () AND 2016 activity_date_key 仅使用 fact_gc_activity_201604_activity_date_key_idx 对 fact_gc_activity_201604 进行索引扫描（成本=0.43..34124.85 行=1088621 宽度=0）（实际time=179.636..4707.148 rows=1088621 loops=1)" " Index Cond: ((activity_date_key >= 20160101) AND (activity_date_key fact_gc_activity_201605 上的 Seq Scan (cost=0.00..43008.71 rows=1116181 width=0) (实际时间=157.550..13863.706 rows=1094721 loops=1)" " Filter: ((activity_d ate_key >= 20160101) AND (activity_date_key 仅索引扫描使用 fact_gc_activity_201608_activity_date_key_idx on fact_gc_activity_201608 (cost=0.43..1281.07 rows=37832 width=0)实际时间=0.058..19.571 行=34741 循环=1)"" 索引条件：((activity_date_key >= 20160101) AND (activity_date_key fact_gc_activity_201607 上的 Seq Scan (cost=0.00..64043.08 rows=1670672 width=0) (实际时间=0.029..765.421 rows=1653358 loops=1)" " Filter: ((activity_date_key >= 20160101) AND (activity_date_key 对 fact_gc_activity_201606 的 Seq 扫描（成本 = 0.00..63368.72 行 =1644648 宽度 = 0）（实际时间 = 0.030..81989.732 行 = 1615197 循环 = 1） " 过滤器：((activity_date_key >= 20160101) AND (activity_date_key

配置设置：- shared_buffers：4GB - Effective_cache_size：2049MB - work_mem：10MB - default_statistics_target：100