Postgres Pro
Downloads
Home   >   mailing lists

Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5 - Mailing list pgsql-general

From David Rowley
Subject Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5
Date
Msg-id CAApHDvpPdBTYBmR4yxpphNkP+ULmzPAOfqzf0=QUTycDtP7Bhg@mail.gmail.com
Whole thread Raw
In response to Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5
List pgsql-general
Tree view 
On Mon, 20 Feb 2023 at 13:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I suspect most of the remaining performance discrepancy is just triggered
> by having to pass the extra always-NULL column forward through the various
> plan steps.  We could teach createplan.c to generate a WindowAgg plan node
> that omits the useless column from ordNumCols/ordColIdx/etc, but I'm not
> sure if that'd save much in itself.  (The comment in create_windowagg_plan
> shows we already thought about that and decided it wasn't worth the
> trouble.)

I wonder what the comment had in mind when it said it doesn't seem
worth it.  Doing an if (IsA(tle->expr, Const)) continue; seems pretty
simple and low-cost.  I've not looked at what the comment mentions
about RANGE OFFSET.  Assuming we'd need to not remove any ORDER BY
clauses when the WindowClause is doing that.

> Getting rid of the useless targetlist column altogether would
> be way more invasive, and I'm not inclined to try.

Yeah, that would likely add more complexity than it would be worth.

David

pgsql-general by date:

Previous
From: Mikhail Balayan
Date:
Subject: Re: Automatic aggressive vacuum on almost frozen table takes too long
Next
From: Stephen Frost
Date:
Subject: Re: can't get psql authentication against Active Directory working