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
David Rowley writes:
> On Wed, 17 Jan 2024 at 15:28, Maiquel Grassi wrote:
>> On Wed, 17 Jan 2024 at 14:36, David Rowley 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
On Wed, 17 Jan 2024 at 15:28, Maiquel Grassi wrote:
> On Wed, 17 Jan 2024 at 14:36, David Rowley 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
As far as I see your proposal, you want to allow something that is
undefined to be reversed. I don't think this is a good idea at all.
As mentioned by others, you should have ORDER BY clauses and just add
a DESC.
* Okay, now I'm convinced of that.
If you were looking for something to
As far as I see your proposal, you want to allow something that is
undefined to be reversed. I don't think this is a good idea at all.
As mentioned by others, you should have ORDER BY clauses and just add
a DESC.
If you were looking for something to optimize in this rough area, then
perhaps
On Wed, 17 Jan 2024 at 08:51, Michał Kłeczek wrote:
> I think that’s the main issue: what (semantically) does row_number() mean in
> that case? You could equally well generate random numbers?
Well, not quite random as at least row_number() would ensure the
number is unique in the result set.
But as you are the one arguing for the new feature demonstrating that the
status quo is deficient is your job.
--//--
I performed these three tests(take a look below) quite simple but functional,
so that we can get an idea of the performance. Apparently, we have a higher
cost in using
The people in this community are quite capable and willing to write a contrary
opinion to mine. Not sure how to make “this new proposed function shouldn’t be
added to core”, and trying to explain why not, non-oppressive. I can add
“thank you for taking the time to try and improve PostgreSQL”
However, initially, I have one more obstacle in your feedback. If I use
count(*) over() - row_number() over(), it gives me an offset of one unit. To
resolve this, I need to add 1.
This way, simulating a reverse row_number() becomes even more laborious.
I don’t really understand why you think
You can do:
-(ROW_NUMBER() OVER ()) AS descending
(note “-“ in front)
I don't have a base column to use for "order by,"
I think that’s the main issue: what (semantically) does row_number() mean in
that case? You could equally well generate random numbers?
--//--
What I want to do is
> On 16 Jan 2024, at 16:51, Maiquel Grassi wrote:
>
>
> Imagine I have a dataset that is returned to my front-end, and I want to
> reverse enumerate them (exactly the concept of Math enumerating integers).
> The row_number does the ascending enumeration, but I need the descending
>
I doubt it is materially different, you need that count regardless so the
effort is expended no matter if you put it in an SQL expression or build it
into the window function. But as you are the one arguing for the new feature
demonstrating that the status quo is deficient is your job.
Hi,
Count() over() - row_number() over()
But if my dataset is significantly large? Wouldn't calling two window
functions instead of one be much slower?
Is count() over() - row_number() over() faster than row_number_desc() over()?
Maiquel.
On Tuesday, January 16, 2024, Maiquel Grassi wrote:
> Hello David, how are you?
>
> Firstly, I apologize if I wasn't clear in what I intended to propose. I
> used a very specific example here, and it wasn't very clear what I really
> wanted to bring up for discussion.
>
> I understand that it's
enumeration "row_number desc"
function?
Regards,
Maiquel O. Grassi.
De: David G. Johnston
Enviado: terça-feira, 16 de janeiro de 2024 11:30
Para: Maiquel Grassi
Cc: pgsql-hack...@postgresql.org
Assunto: Re: New Window Function: ROW_NUMBER_DESC() OVER
On Tuesday, January 16, 2024, Maiquel Grassi wrote:
> Hi developers,
>
> I was working on loans and bank financing, specifically focusing on
> Amortization Systems. I had the need to reverse the counter for the total
> number of installments or for a specific set of installments. This
>
16 matches
Mail list logo
