From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com>, pghackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Date: | 2023-01-05 07:14:49 |
Message-ID: | CAApHDvp=TK8uY903nDD1C9V1ywyFYnKR_dhTAFt_qUEkXkuizQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 5 Jan 2023 at 16:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > Additionally, it's also not that clear to me that sorting by more
> > columns in the sort below the WindowAgg would always be a win over
> > doing the final sort for the ORDER BY. What if the WHERE clause (that
> > could not be pushed down before a join) filtered out the vast majority
> > of the rows before the ORDER BY. It might be cheaper to do the sort
> > then than to sort by the additional columns earlier.
>
> That's certainly a legitimate question to ask, but I don't quite see
> where you figure we'd be sorting more rows? WHERE filtering happens
> before window functions, which never eliminate any rows. So it seems
> like a sort just before the window functions must sort the same number
> of rows as one just after them.
Yeah, I didn't think the WHERE clause thing out carefully enough. I
think it's only the WindowClause's runCondition that could possibly
filter any rows between the Sort below the WindowAgg and before the
ORDER BY is evaluated.
David
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-01-05 07:23:40 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Previous Message | David G. Johnston | 2023-01-05 07:12:34 | Re: Resolve UNKNOWN type to relevant type instead of text type while bulk update using values |