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() ?  (Maiquel Grassi <grassi@hotmail.com.br>)
Список 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 по дате отправления:

Предыдущее
От: "Li, Yong"
Дата:
Сообщение: Re: locked reads for atomics
Следующее
От: Yongtao Huang
Дата:
Сообщение: Re: Fix a typo of func DecodeInsert()