From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> |
Cc: | pghackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Vik Fearing <vik(at)postgresfriends(dot)org> |
Subject: | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Date: | 2023-01-07 22:36:58 |
Message-ID: | CAApHDvqD0B21J2Z44G+_KEf8AmqHPjhuwbX4b6NB2eyP2CZo=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 8 Jan 2023 at 05:45, Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> wrote:
> Attached patch with test cases.
I can look at this in a bit more detail if you find a way to fix the
case you mentioned earlier. i.e, push the sort down to the deepest
WindowAgg that has pathkeys contained in the query's ORDER BY
pathkeys.
EXPLAIN (COSTS OFF)
SELECT empno,
depname,
min(salary) OVER (PARTITION BY depname ORDER BY empno) depminsalary,
sum(salary) OVER (PARTITION BY depname) depsalary
FROM empsalary
ORDER BY depname, empno, enroll_date;
QUERY PLAN
-----------------------------------------------
Incremental Sort
Sort Key: depname, empno, enroll_date
Presorted Key: depname, empno
-> WindowAgg
-> WindowAgg
-> Sort
Sort Key: depname, empno
-> Seq Scan on empsalary
(8 rows)
You'll also need to pay attention to how the has_runcondition is set.
If you start pushing before looking at all the WindowClauses then you
won't know if some later WindowClause has a runCondition. Adding an
additional backwards foreach loop should allow you to do all the
required prechecks and find the index of the WindowClause which you
should start pushing from.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Koshakow | 2023-01-07 22:52:16 | Re: Infinite Interval |
Previous Message | David Rowley | 2023-01-07 22:26:08 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |