postgresql中corr函数要求输入为double precision类型，不接受整型直接输入，否则可能因隐式转换失败或大整数乘法溢出导致精度偏差；必须显式转换如sales_cnt::double precision，且corr基于covar_pop（总体协方差）计算，非样本版本。
PostgreSQL中CORR函数必须传double precision类型
CORR(expr1, expr2)在PostgreSQL里不接受整型直接输入，否则可能因隐式转换失败或大整数乘法溢出导致精度偏差。例如对两个INT列直接调用CORR(sales_cnt, profit)，引擎会尝试转成DOUBLE PRECISION，但若原始值过大（如超2⁵³），乘积项会丢失低位精度。
稳妥做法是显式转换：
- 用
sales_cnt::DOUBLE PRECISION或CAST(sales_cnt AS DOUBLE PRECISION) - 若列本身是
NUMERIC，也建议先转DOUBLE PRECISION再进CORR，避免NUMERIC高精度运算拖慢聚合速度 - 别依赖自动转换——PostgreSQL不会为CORR特设宽松类型策略，报错
ERROR: function corr(numeric, numeric) does not exist很常见
COVAR_POP和COVAR_SAMP的区别直接影响CORR结果解释
CORR底层调用的是COVAR_POP除以两个STDDEV_POP的乘积，不是COVAR_SAMP。这意味着它默认按「总体」而非「样本」建模：分母用n而非n−1。
实际影响在于小数据集：
- 当有效行数
n 时，<code>COVAR_POP比COVAR_SAMP略小（因分母更大），导致CORR绝对值轻微压低 - 若你后续要对接统计软件（如R的
cor()默认用method="pearson"，即样本版本），需注意这个差异不是bug，而是定义不同 - 无法通过参数切换——PostgreSQL没提供
CORR_SAMP这类变体，硬要样本版相关系数得手动写：COVAR_SAMP(x,y) / (STDDEV_SAMP(x) * STDDEV_SAMP(y))
CORR不能嵌套在GROUP BY外层聚合中
写SELECT region, CORR(sales, cost) FROM t GROUP BY region合法；但写SELECT CORR(SUM(sales), SUM(cost)) FROM t GROUP BY region会报ERROR: aggregate function calls cannot be nested。
根本原因在于CORR不是“对聚合结果算相关”，而是“对成对原始观测值计算协方差关系”。一旦先SUM，就只剩单个标量，没了(xᵢ,yᵢ)序列。
正确路径只有两条：
- 用子查询先生成指标对宽表：
SELECT CORR(avg_sales, avg_cost) FROM (SELECT region, AVG(sales) AS avg_sales, AVG(cost) AS avg_cost FROM t GROUP BY region) _ - 用窗口函数做分组内相关性：
CORR(sales, cost) OVER (PARTITION BY region)——此时每行返回的是该region所有行的CORR值，不是逐行相关系数 - 注意NULL处理逻辑：任意一列值为
NULL的行，整行被排除，不插值、不补0
窗口模式下CORR的OVER子句容易漏掉ORDER BY语义
CORR(x,y) OVER (PARTITION BY category ORDER BY date)看似合理，但PostgreSQL要求ORDER BY存在时，CORR会变成累积相关系数（cumulative），即从第一行到当前行的滑动窗口计算，不是整个分区的固定值。
这常导致误读：
- 第1行：只有一对
(x₁,y₁)→CORR为NULL（至少需2点） - 第5行：算的是前5行的
CORR，不是全分区 - 若你本意是“每个category内按date排序后整体相关性”，就不该加
ORDER BY，只留PARTITION BY category - 检查执行计划时，留意
WindowAgg节点是否带frame_clause——有则为累积，无则为分区全量
真正难的不是写对语法，是想清楚你要的到底是「分组内静态相关强度」，还是「随时间演化的动态关联趋势」。前者用聚合模式，后者才用带ORDER BY的窗口，且得接受它是累积值。多数业务场景其实只需要前者。
