From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Maiquel Grassi <grassi(at)hotmail(dot)com(dot)br>, Michał Kłeczek <michal(at)kleczek(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New Window Function: ROW_NUMBER_DESC() OVER() ? |
Date: | 2024-01-17 04:13:35 |
Message-ID: | 1952556.1705464815@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:
> On Wed, 17 Jan 2024 at 15:28, Maiquel Grassi <grassi(at)hotmail(dot)com(dot)br> wrote:
>> On Wed, 17 Jan 2024 at 14:36, David Rowley <dgrowleyml(at)gmail(dot)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 possible Proof 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
From | Date | Subject | |
---|---|---|---|
Next Message | Yongtao Huang | 2024-01-17 04:18:12 | Re: Fix a typo of func DecodeInsert() |
Previous Message | Li, Yong | 2024-01-17 03:48:43 | Re: locked reads for atomics |