Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: xinwen@stu.scu.edu.cn, pgsql-bugs@lists.postgresql.org
Date: 2023-03-11T17:23:56Z
Lists: pgsql-bugs
David Rowley <dgrowleyml@gmail.com> writes: > On Fri, 10 Mar 2023 at 05:09, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> How is this even a little bit sane? > I don't think it is. I've not looked in detail yet, but I think we > might be able to do something in check_output_expressions() so that we > track the targetIsInAllPartitionLists() separately. Maybe > unsafeColumns[] needs to become an enum type that has UNSAFE, SAFE, > WINDOW_RUNCONDITION_ONLY and then change things so we never make a > runCondition when the qual is UNSAFE. > Anyway, I'll give it more thought and aim to come up with a patch > early next week. Why can't we simply *remove* all this logic from subquery pushdown? I would expect that what happens in useful cases is that we push down the (safe) qual and then during planning of the subquery we see a WHERE clause matching the window run condition and work with that. So this all seems redundant, quite aside from being faulty. regards, tom lane
Commits
-
Fix incorrect logic for determining safe WindowAgg run conditions
- 371e3daaa53d 15.3 landed
- eb7d043c9bba 16.0 landed
-
Teach planner and executor about monotonic window funcs
- 9d9c02ccd1ae 15.0 cited