我有一个表，其中包含3个字段（用户名，target_value，score），该字段由用户名（〜400,000）和target_value（〜4000）的全数和外部计算而得，得出的总行数约为16亿
我在此表上的所有查询都将采用
的格式SELECT *
FROM _table
WHERE target_values IN (123, 456)
我的最初版本包括一个关于target_values的BTREE索引，但是我最终花了45分钟的时间在该索引的BITMAP HEAP SCAN上。 我还一直在研究BRIN索引，分区和表集群，但是由于将每种方法应用于表都需要花费数小时，因此我无法完全蛮力地对每个选项进行性能测试。
在Postgres 10中处理具有非常“块状”数据的单个海量表有哪些建议？
答案 0 :(得分：3)
如果表是两个数据集的交叉联接，为什么不存储单个表并根据需要计算联接？数据库擅长于此。
根据您的描述，如果您在表上运行CLUSTER以物理方式按索引顺序对其进行重写，那么我期望性能会有所提高。然后，您将不得不访问较少的表块。
不幸的是，CLUSTER将花费很长时间，使该表不可用，必须定期重复。</ p>
一个更好的选择是用target_value对表进行分区。 4000个分区有点多，所以也许可以使用列表分区将多个分区捆绑在一起成为一个分区。
这将使您的查询仅对几个分区执行快速顺序扫描。这也将使自动真空的工作更加轻松。
但是，最重要的是，如果您从表中选择很多行，那么它将总是花费很长时间。