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

Question

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

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

在所有外键/ id列上都有一个Fact表，其中包含大约9500万行b-tree索引。外键列是smallint / integer数据类型的混合。它们都是单列索引。还有一些措施，例如我们用于汇总的金额（sum / avg）。这些字段未编入索引。该表每天使用Pentaho的JDBD插入/更新语句进行更新。该表也由activity_date_key分区。

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

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

赖安

Answer 1

以下是我的设置的一些其他信息以及目前为止的一些问题答案：

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

我确实想考虑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之间：

＆＃34;聚合（成本= 372804.89..372804.90行= 1宽度= 0）（实际时间= 121284.418..121284.418行= 1个循环= 1）＆＃34; ＆＃34;缓冲区：共享命中= 72295读取= 47564＆＃34; ＆＃34; - ＆GT;追加（成本= 0.00..347567.97行= 10094768宽度= 0）（实际时间= 350.581..118020.641行= 10023451循环= 1）＆＃34; ＆＃34;缓冲区：共享命中= 72295读取= 47564＆＃34; ＆＃34; - ＆GT; seq扫描fact_gc_activity（成本= 0.00..0.00行= 1宽度= 0）（实际时间= 0.001..0.001行= 0循环= 1）＆＃34; ＆＃34;过滤：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34; - ＆GT;仅使用fact_gc_activity_201601上的fact_gc_activity_201601_activity_date_key_idx进行扫描（成本= 0.43..54563.87行= 1748572宽度= 0）（实际时间= 350.577..5734.825行= 1748572循环= 1）＆＃34; ＆＃34;索引条件：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;堆提取：0＆＃34; ＆＃34;缓冲区：共享命中= 2读取= 4880＆＃34; ＆＃34; - ＆GT;仅使用fact_gc_activity_201602上的fact_gc_activity_201602_activity_date_key_idx进行扫描（成本= 0.43..41641.89行= 1331873宽度= 0）（实际时间= 183.811..3071.842行= 1331873循环= 1）＆＃34; ＆＃34;索引条件：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;堆提取：0＆＃34; ＆＃34;缓冲区：共享命中= 2读= 3737＆＃34; ＆＃34; - ＆GT;仅使用fact_gc_activity_201603上的fact_gc_activity_201603_activity_date_key_idx进行扫描（成本= 0.43..45535.79行= 1456368宽度= 0）（实际时间= 171.306..3069.430行= 1456368循环= 1）＆＃34; ＆＃34;索引条件：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;堆提取：0＆＃34; ＆＃34;缓冲区：共享命中= 2读取= 4086＆＃34; ＆＃34; - ＆GT;仅使用fact_gc_activity_201604上的fact_gc_activity_201604_activity_date_key_idx进行扫描（成本= 0.43..34124.85行= 1088621宽度= 0）（实际时间= 179.636..4707.148行= 1088621循环= 1）＆＃34; ＆＃34;索引条件：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;堆提取：0＆＃34; ＆＃34;缓冲区：共享命中= 2读= 3076＆＃34; ＆＃34; - ＆GT; seq Scan on fact_gc_activity_201605（cost = 0.00..43008.71 rows = 1116181 width = 0）（实际时间= 157.550..13863.706 rows = 1094721 loops = 1）＆＃34; ＆＃34;过滤：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;缓冲区：共享命中= 5374读取= 20892＆＃34; ＆＃34; - ＆GT;仅使用fact_gc_activity_201608上的fact_gc_activity_201608_activity_date_key_idx进行扫描（成本= 0.43..1281.07行= 37832宽度= 0）（实际时间= 0.058..19.571行= 34741循环= 1）＆＃34; ＆＃34;索引条件：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;堆提取：0＆＃34; ＆＃34;缓冲区：共享命中= 124＆＃34; ＆＃34; - ＆GT; seq Scan on fact_gc_activity_201607（cost = 0.00..64043.08 rows = 1670672 width = 0）（实际时间= 0.029..765.421行= 1653358循环= 1）＆＃34; ＆＃34;过滤：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;缓冲区：共享命中= 38983＆＃34; ＆＃34; - ＆GT; seq Scan on fact_gc_activity_201606（cost = 0.00..63368.72 rows = 1644648 width = 0）（实际时间= 0.030..81989.732 rows = 1615197 loops = 1）＆＃34; ＆＃34;过滤：（（activity_date_key＆gt; = 20160101）AND（activity_date_key＆lt; = 20160801））＆＃34; ＆＃34;缓冲区：共享命中= 27806读= 10893＆＃34; ＆＃34;总运行时间：121284.642 ms＆＃34;

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

Answer 2

尝试调整postgresql，在＆＃34; postgresql.conf＆＃34;你会发现很多参数可以加速你的postgresql，你可以查询＆＃34; work_mem＆＃34;但请注意您拥有的连接数量，会让您了解如何设置参数，或者阅读此pgtune以获得清晰的愿景。