| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Chengpeng Yan <chengpeng_yan(at)outlook(dot)com> |
| Cc: | "imchifan(at)163(dot)com" <imchifan(at)163(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Subject: | Re: BUG #19533: Wrong results from WindowAgg run-condition pushdown on count() with EXCLUDE CURRENT ROW |
| Date: | 2026-06-29 00:39:20 |
| Message-ID: | CAMbWs4-6umOecRifmC88RW0SHWDAvb4c3-VD8XQ3NJufsUyUOQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sun, Jun 28, 2026 at 1:53 AM Chengpeng Yan <chengpeng_yan(at)outlook(dot)com> wrote:
> The attached patch takes the conservative route: int8inc_support() no
> longer reports count() as monotonic when the window frame has
> FRAMEOPTION_EXCLUSION. The added regression tests cover the reported
> case, related EXCLUDE variants, and a count(*) case. They also check
> that the excluded-frame query keeps a normal Filter instead of a
> WindowAgg Run Condition.
I think the fix is on the right track. One nit is that it might be
better to use if/else if structure here. The other nit is that the
test case is over-heavy; it should be kept as minimal as possible.
> Thoughts welcome on whether this is the right boundary, or whether some
> narrower excluded-frame cases should still prove monotonicity
> separately.
I wonder if we should still support count(*) with EXCLUDE CURRENT ROW,
as that always removes exactly one row, so it is still monotonic.
+ if ((frameOptions & FRAMEOPTION_EXCLUSION) &&
+ ((frameOptions & FRAMEOPTION_EXCLUSION) !=
FRAMEOPTION_EXCLUDE_CURRENT_ROW ||
+ req->window_func->winfnoid != F_COUNT_))
+ monotonic = MONOTONICFUNC_NONE;
- Richard
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tender Wang | 2026-06-29 01:22:49 | Re: BUG #19534: Qual pushdown across a window subquery is unsafe with nondeterministic partition collations |
| Previous Message | Bharath Rupireddy | 2026-06-28 23:34:59 | Re: BUG #19536: UPDATE RETURNING OLD value is stale after concurrent update when table has a BEFORE UPDATE trigger |