This was a simple omission in
9d9c02ccd where the code didn't correctly
set the operator to use in the run condition OpExpr when the window
function was both monotonically increasing and decreasing.
Bug discovered by Julien Roze, although he did not report it.
Reported-by: Phil Florent
Discussion: https://postgr.es/m/PA4P191MB160009A09B9D0624359278CFBA9F9@PA4P191MB1600.EURP191.PROD.OUTLOOK.COM
Backpatch-through: 15, where
9d9c02ccd was added
{
*keep_original = false;
runopexpr = opexpr;
+ runoperator = opexpr->opno;
break;
}
3 | sales | 4800 | 3
(8 rows)
+-- Ensure we get the correct run condition when the window function is both
+-- monotonically increasing and decreasing.
+EXPLAIN (COSTS OFF)
+SELECT * FROM
+ (SELECT empno,
+ depname,
+ salary,
+ count(empno) OVER () c
+ FROM empsalary) emp
+WHERE c = 1;
+ QUERY PLAN
+--------------------------------------------------------
+ WindowAgg
+ Run Condition: (count(empsalary.empno) OVER (?) = 1)
+ -> Seq Scan on empsalary
+(3 rows)
+
-- Some more complex cases with multiple window clauses
EXPLAIN (COSTS OFF)
SELECT * FROM
FROM empsalary) emp
WHERE c <= 3;
+-- Ensure we get the correct run condition when the window function is both
+-- monotonically increasing and decreasing.
+EXPLAIN (COSTS OFF)
+SELECT * FROM
+ (SELECT empno,
+ depname,
+ salary,
+ count(empno) OVER () c
+ FROM empsalary) emp
+WHERE c = 1;
+
-- Some more complex cases with multiple window clauses
EXPLAIN (COSTS OFF)
SELECT * FROM