| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| 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 03:12:04 |
| Message-ID: | 2410904.1672888324@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | houzj.fnst@fujitsu.com | 2023-01-05 03:37:46 | RE: Perform streaming logical transactions by background workers and parallel apply |
| Previous Message | Thomas Munro | 2023-01-05 03:11:00 | Re: pg_upgrade test failure |