From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
Cc: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com>, David Rowley <dgrowleyml(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 02:48:05 |
Message-ID: | 2408233.1672886885@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vik Fearing <vik(at)postgresfriends(dot)org> writes:
> On 1/4/23 13:07, Ankit Kumar Pandey wrote:
>> Also, one thing, consider the following query:
>> explain analyze select row_number() over (order by a,b),count(*) over
>> (order by a) from abcd order by a,b,c;
>> In this case, sorting is done on (a,b) followed by incremental sort on c
>> at final stage.
>> If we do just one sort: a,b,c at first stage then there won't be need to
>> do another sort (incremental one).
> This could give incorrect results.
Mmmm ... your counterexample doesn't really prove that. Yes,
the "rank()" step must consider only two ORDER BY columns while
deciding which rows are peers, but I don't see why it wouldn't
be okay if the rows happened to already be sorted by "c" within
those peer groups.
I don't recall the implementation details well enough to be sure
how hard it would be to keep that straight.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-01-05 03:11:00 | Re: pg_upgrade test failure |
Previous Message | David Rowley | 2023-01-05 02:30:59 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |