我有一张看起来像这样的桌子:
create table room_server_metrics (
namespace varchar(36) not null,
session_id varchar(36) not null,
primary key (namespace, session_id),
created_at timestamptz not null default now(),
updated_at timestamptz not null default now(),
);
当我尝试总结所有会话的长度时,我得到:
database=> select sum(updated_at - created_at) as total_time from room_server_metrics;
total_time
----------------------------
94 days 60951:01:56.381483
94 天 + 60951 小时约为 2633 天。
我不确定打印输出是否显示 94 天作为一个更容易阅读的指标,但如果我在几秒钟内打印出增量,我会得到:
database=> select extract(epoch from sum(updated_at - created_at)) as total_time from room_server_metrics;
total_time
----------------------------
227546617.181704
227546617.181704 秒也是~2633 天。
为什么第一个查询没有减少超过 94 天的小时数?我一辈子都搞不懂这个哈哈。
最大
感谢 Adrian 的评论和一些 postgres 文档研究,我发现了这一点:
内部间隔值存储为月、日和秒。 这样做是因为一个月中的天数不同,并且一天 如果夏令时调整为 23 或 25 小时 涉及。月份和日期字段是整数,而秒字段是 字段可以存储分数。因为间隔通常是从创建的 常量字符串或时间戳减法,这种存储方法有效 在大多数情况下都很好。函数 justify_days 和 justify_hours 是 可调整超出正常范围的日期和时间 范围。
postgres 似乎获取每行的时间跨度并分别将天/小时/分钟相加。在本例中,有 94 行在求和的时间间隔内至少有 1 天的时间。使用
justify_hours
函数确实解决了问题:
database=> select justify_hours(sum(updated_at - created_at)) as total_time from room_server_metrics;
total_time
---------------------------
2637 days 08:33:22.773599