Postgresql 性能：使用 pg_timezone_names 的最佳方式是什么？

Question

对于全局应用程序，我们仅使用没有时区的时间戳。但是，为了方便用户，有些事情必须在当地时间。为了让它工作，我们必须处理从本地到 UTC 的转换，包括处理夏令时。我们不需要低于分钟的精度。

pg_timezone_names 包含我们需要的一切，包括时区名称的明确长字符串（例如，'US/Eastern'）、间隔 utc_offset 和布尔值 is_dst。 （我假设后两个值会随着 dst 边界的变化而变化。）

假设我们最终拥有数百万用户，我正在尝试找出最佳性能模型。以下是正在考虑的选项：

1. 位置表中的 TZ 名称字符串（'US/Eastern'）。每次需要进行时间转换（从本地到 UTC 或返回）时，我们直接调用 pg_timezone_names 来获取该时区的 utc_offset。 （这是假设视图索引良好。）当然，在位置表中的字符串上建立索引。
2. 本地表 time_zones 复制 pg_timezone_names，但添加了 id 和 boolean in_use 列（并删除了缩写）。在位置表中包含 tz_id 作为外键而不是字符串。

在本地表的情况下，使用一个在 26 小时左右的每个小时后一分钟全天候触发的过程，以便时区可以更改，该过程检查刚刚通过两个的 in_use 时区列表AM Sunday（基于本地存储的偏移量）并调用 pg_timezone_names 以获取更新的偏移量和 is_dst 值。每当一个区域开始使用并确保它具有正确的值时，都会触发本地表检查的更新。

问题是，每次需要时先评估位置表中的索引字符串，然后从 pg_timezone_names 中提取偏移量，或者使用本地 time_zones 表通过 FK 提取偏移量，是否更快。我认为第二个会快得多，因为它避免了初始字符串处理，但这实际上取决于视图 pg_timezone_names 的速度。

Answer 1

在对此进行了更多研究并与同事讨论后，我意识到上述第二个选项存在缺陷。该选项确实会快很多，但它仅在希望将当前 utc_offset 拉到一个时区时才有效。如果需要对不是当前的时间戳或时间戳范围执行此操作，则需要调用内置的 postgres 视图，因此可以在时区调用每个时间戳，这将为该特定时间进行适当的夏令时转换时间戳。

速度较慢，但​​我认为无法改进，除非只对当前的时间戳转换感兴趣，这是极不可能的。

所以我回到第一个选项，不再需要在本地表中索引时区字符串，因为它永远不会被搜索或排序。