我将在共享服务器上按20M行的顺序对表进行分区，共享服务器有大量磁盘空间，但RAM有限：
dt DATE NOT NULL,
id char(9) NOT NULL,
bintime int NOT NULL,
avg_score numeric(5,2) NOT NULL
我的前任将
date拆分为不同的数字组件，可能是为了针对不同的未来聚合查询进行优化，因此有一个表包含：id char(9) NOT NULL,
yyyy smallint NOT NULL,
mm smallint NOT NULL,
dd smallint NOT NULL,
dow smallint NOT NULL,
bintime int NOT NULL,
avg_score numeric(5,2) NOT NULL
我想知道这样做是否值得/有益。同样，空间不是问题，但RAM是问题。
根据我的研究，我甚至可以让每个分组列（yyyy、mm等）都是enum type。我看到有人在PostgreSQL列表上询问关于a similar question的问题，但这是将日期存储为int以便排序，而不是分组。他们得到的答案是
记住迈克尔杰克逊（和其他人）要说的话
这：
“程序优化的第一条规则是：不要这样做。
第二次
程序优化规则（仅限专家！）：暂时不要这样做。“
首先，在数据中添加一个额外的列意味着
查询时需要将数据塞进缓存，因此即使原始数据
整数与日期排序更快，“优化”仍然可以
是因为更胖的元组造成的净损失如果你愿意和
只有基于整数的日期，这可能会有帮助，但看起来
非常痛苦，不值得考虑，除非你遇到
麻烦。
最佳答案
我调查的初步结果。
表创建
不带ymd：
时间35:34分钟（来自Python脚本）
表大小：538MB
与ymd：
时间59:17分钟到4:30:14小时（从pgadmin查询窗口）
表大小：562 MB
汇总到月工作日
没有基督教青年会：1:42
与基督教青年会：1:36
我还没有用索引来测试。
初步结论：
聚合查询性能的边际提高不值得大量创建查询时间。表的大小差异可以忽略不计（令人惊讶）。请随意添加更多测试建议。