我有一个包含 3 个字段(用户名、target_value、分数(的表格，这些字段由用户名 (~400,000( 和 target_value (~4000( 的完整交叉和计算分数生成，导致总行数为 ~16 亿。
我在这个表上的所有查询都将采用以下格式
SELECT *
FROM _table
WHERE target_values IN (123, 456)
我的初始版本包括target_values上的 BTREE 索引，但我最终花了 45 分钟对该索引进行位图堆扫描。 我也一直在研究 BRIN 索引、分区和表聚类，但由于将每种方法应用于表需要数小时，因此我无法完全暴力破解每个选项并测试性能。
在 Postgres 10 中处理具有非常"块状"数据的单个大型表有哪些建议？
如果表是两个数据集的交叉连接，为什么不存储各个表并根据需要计算连接？数据库擅长于此。
从您的描述中，如果您在表上运行CLUSTER以按索引顺序物理重写它，我希望性能会提高。然后，您必须访问更少的表块。
不幸的是，CLUSTER需要很长时间，使表格不可用，必须定期重复。
可能更好的替代方法是按target_value对表进行分区。 4000 个分区有点多，所以也许使用列表分区将几个分区捆绑到一个分区中。
这将允许查询仅对少数几个分区执行快速顺序扫描。它还将使自动吸尘器的工作更容易。
但是，底线是，如果从表中选择大量行，则始终需要很长时间。