percentile_cont 和 percentile_disc 都没有计算 PostgreSQL 9.6.3 中所需的第 75 个百分位数答案

【问题标题】：Neither percentile_cont nor percentile_disc are calculating the desired 75th percentile in PostgreSQL 9.6.3percentile_cont 和 percentile_disc 都没有计算 PostgreSQL 9.6.3 中所需的第 75 个百分位数
【发布时间】：2017-09-11 19:36:41
【问题描述】：

使用百分位函数，但我没有得到想要的输出。我会说“不正确”，但这些功能可能按预期工作，我只是没有正确理解它们。

这些是我正在使用的数字：

我对@987654323@ 的理解是，如果计数是偶数，它将聚合两个数字，因为它将添加它们然后除以二。我对percentile_disc 的理解是，如果计数是偶数，它只会选择最小的数字。

这是我对以第 50 位（中位数）为例计算百分位数的理解：

如果数字（n）的个数是奇数，则选择中间的数字；如果数字是偶数，则将中间的两个数字平均。所以在这种情况下，有 32 个数字，所以中位数 = (358625 + 364999.92) / 2 = 361812.46。 percentile_cont 返回正确的值，因为它平均了两个值； percentile_disc 返回不正确的值，因为它选择了两者中的最小值。

关于其他百分位数，例如第 10 个，我的理解是您将百分位数乘以数字的数量 (n) 以获得索引：.10 * 32 = 3.2 index 在这种情况下。然后你应该四舍五入到最接近的整数，这就是你的百分位值。如果索引是整数，则将索引中的数字与紧随其后的数字平均。

在这种情况下，percentile_cont 是错误的，因为它返回 251500，这甚至不是我能得出的数字。我能得到的最接近的是平均24000, 250000, 265000，即251666.67。 percentile_disc 返回250000 的正确结果。

但真正重要的是这个：第 75 个。根据我的计算，它应该返回469250。 index = (32*.75) = 24，并且该索引应导致 (463500 + 475000) = 469250。 percentile_disc 返回463500； percentile_cont 返回466375，我这辈子都无法达到这个数字。

这是我的查询：

SELECT 
    itemcode, 
    COUNT(itemcode) AS n, 
    PERCENTILE_DIST(0.10) WITHIN GROUP (ORDER BY price) AS 10th,
    PERCENTILE_DIST(0.25) WITHIN GROUP (ORDER BY price) AS 25th,
    PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY price) AS median,
    AVG(price) AS mean,
    PERCENTILE_DIST(0.65) WITHIN GROUP (ORDER BY price) AS 65th,
    PERCENTILE_DIST(0.75) WITHIN GROUP (ORDER BY price) AS 75th,
    PERCENTILE_DIST(0.90) WITHIN GROUP (ORDER BY price) AS 90th
FROM items
WHERE itemcode = 26 AND removed IS NULL
GROUP BY itemcode;

注意：没有removed 不是NULL 的情况。

我需要做些什么才能使其正常工作且保持一致？我是否需要编写一个函数先检查n，然后根据它是偶数还是奇数来决定哪个percentile_disc 或percentile_cont？

SQL 小提琴：http://sqlfiddle.com/#!17/aa09c/9

【问题讨论】：

你能把帖子缩减为一个函数，一个带有样本数据、输出和预期输出的问题吗？

标签： sql database postgresql

【解决方案1】：

将此问题发布到 Reddit 并获得了一些帮助。

显然，除了 Excel 中的 percentile 和 percentile.inc 函数之外，percentile_cont 函数还使用线性插值的 C=1 变体进行计算，如本维基百科中所述：

https://en.wikipedia.org/wiki/Percentile#Second_variant.2C_.7F.27.22.60UNIQ--postMath-00000043-QINU.60.22.27.7F

显然，我一直在使用的是所谓的平均经验分布。

所以 PostgreSQL 的原生函数不能很好地工作，需要创建一个自定义函数，我将在完成后发布。（我怀疑它会使用 9.4 之前的旧 ntile 方法，但仍在研究中）。

但无论如何，这就是它关闭的原因。

【讨论】：