PostgreSQL中精确计数机制的改进
我有一个问题，我已经面对了一段时间，并被忽视了一段时间。数行的问题。我有读一读它很慢，因为PostgreSQL必须验证每一行，因此必须进行顺序扫描。我目前正在使用PostgreSQL 13。
我发现了一些潜在的解决方案：
- 使用估计值。尽管查询单个表时的估计更接近，但使用联接时的结果却相差很远。另外，我需要精确的计数，因为我需要向用户显示确切的数字，就像他做了多少事务一样。
- 使用外部表来维护计数。这里的想法是使用规则或插入触发器后使用
count = count + 1更新计数这里的问题是用户可以添加多个过滤器(如日期、用户is等)，这将改变计数，但外部表只存储计数。
我该怎么解决这个问题？我正在努力把计算的时间缩短到3-4秒以下。目前，一个表中有将近10亿条记录，尽管这个表在每个月被分成12个分区。这有可能吗？
十一个分区不会有插入，但可能有删除操作。用户可以应用筛选器，这将更改任何分区的计数。
我在日期列上使用b树索引。在解释分析中，索引正在被使用，但是由于记录很大，b树索引不能适应RAM，因为它的大小也很大。
表按每个月进行分区，每个分区在日期上都有一个索引，这意味着每个月有一个索引。
回答 2
Database Administration用户
发布于 2021-05-14 10:07:36
有了一个大表，您将无法避免I/O，而且查询永远不会很快。在海量数据上非常快速的聚合并不是PostgreSQL的优点。为此您需要一个列存储(PostgreSQL有一个列存储扩展)。
如果您使用VACUUM表，PostgreSQL可以通过查看可见性映射来避免查找行。
如果11个分区是静态的，只有一个是活动的，则可以存储静态分区的总数，并为活动分区添加行数。如果用户可以应用筛选器，则无法避免实际计算匹配的行数。您可能需要一个总结数据的数据仓库。
Database Administration用户
发布于 2021-05-17 01:49:08
如果您的数据具有正在搜索的可预测值，则可以构建可以加载到RAM中并有效使用的部分索引。
CREATE INDEX table_type_value1
ON table(ordered_value)
WHERE type=value1为查询SELECT ordered_value FROM table WHERE type=value1提供服务
要优化的每个type值都需要一个索引。
在您的描述中，订购列是日期，条件可能是搜索的日期范围(今天、上周等)。
https://dba.stackexchange.com/questions/291306
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号