我们目前正在使用一个汇总表，该表按 UTC 时间每小时汇总用户信息。我们遇到的问题是这个表变得太大并且极大地减慢了我们的系统速度。我们已经完成了为 PostgreSQL 推荐的所有调整技术，但仍然遇到缓慢的情况。
我们的想法是开始按天而不是按小时聚合，但问题是我们允许客户更改时区，这会重新计算当天的数据。
有谁知道如何存储每日摘要，但在切换时区时仍然尊重数字和总数？
使用时间偏移列和“日”字段（日期）（即特定汇总行的日期）来汇总表中的数据。在（时间偏移、日期、其他相关字段）上建立索引，如果可能的话进行集群（大概 PostgresSQL 有集群索引？），一切都应该很好。
我假设您已经了解了所有分区注意事项，例如按用户分区。
根据使用模式，我可以看到几种解决您问题的方法。
每天汇总每个用户选择的数据。如果时区发生更改，请以编程方式重新计算该合作伙伴的总计。如果时区更改不频繁并且当用户更改时区时可能会引入一定的数据延迟，则这是合理的。
如果您的度量相对较少，您可以为每个度量维护 24 列 - 每列描述不同时区中该度量的每日聚合。
如果时区变化频繁并且有很多度量，那么似乎 24 个不同的聚合表将是最佳选择。
我也遇到这个问题了。我采取这样的解决方案：日期类型的数据使用本地时区，其他日期时间类型的数据使用UTC时区，因为统计索引是本地的。另一个原因是现在我们只有本地数据。
我面临同样的问题。我正在考虑按日期和时间（UTC 中的每小时）进行聚合。然后您可以相应地获取您想要的任何时区的数据。不幸的是，如果您需要支持有 45/30/15 分钟偏移的时区，这将不起作用。 然后您可以按 15 分钟聚合数据。解决方案取决于要聚合的数据量。
我们有非常相似的情况，我们想要在报告表中存储按天聚合的数据，但我们也想根据所有时区调整/选择数据。
就像 @Jakub Pomykała 的建议一样，我们已经尝试每天聚合 15 分钟的数据块，并且效果很好。
我们将拥有大量的用户数据，但我们不确定它是否是可扩展的解决方案。
@Russ Bradberry：您的问题采用了哪种方法。