Re: New Window Function: ROW_NUMBER_DESC() OVER() ?
| От | Tom Lane |
|---|---|
| Тема | Re: New Window Function: ROW_NUMBER_DESC() OVER() ? |
| Дата | |
| Msg-id | 1952556.1705464815@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: New Window Function: ROW_NUMBER_DESC() OVER() ? (David Rowley <dgrowleyml@gmail.com>) |
| Ответы |
RE: New Window Function: ROW_NUMBER_DESC() OVER() ?
|
| Список | pgsql-hackers |
David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 17 Jan 2024 at 15:28, Maiquel Grassi <grassi@hotmail.com.br> wrote:
>> On Wed, 17 Jan 2024 at 14:36, David Rowley <dgrowleyml@gmail.com> wrote:
>>> If you were looking for something to optimize in this rough area, then
>>> perhaps adding some kind of "Backward WindowAgg" node (by overloading
>>> the existing node) to allow queries such as the following to be
>>> executed without an additional sort.
>>>
>>> SELECT a,row_number() over (order by a desc) from t order by a;
>> David, considering this optimization, allowing for that, do you believe it is plausible to try advancing towards a
possibleProof of Concept (PoC) implementation?
> I think the largest factor which would influence the success of that
> would be how much more complex nodeWindowAgg.c would become.
Even if a workable patch for that is presented, should we accept it?
I'm having a hard time believing that this requirement is common
enough to justify more than a microscopic addition of complexity.
This whole area is devilishly complicated already, and I can think of
a bunch of improvements that I'd rate as more worthy of developer
effort than this.
regards, tom lane
В списке pgsql-hackers по дате отправления: