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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kirk Wolak <wolakk(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5
Date: 2023-02-20 09:09:26
Message-ID: CAApHDvpPdBTYBmR4yxpphNkP+ULmzPAOfqzf0=QUTycDtP7Bhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 20 Feb 2023 at 13:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Frost 2023-02-20 14:17:23 Re: can't get psql authentication against Active Directory working
Previous Message Masahiko Sawada 2023-02-20 08:22:50 Re: Support logical replication of DDLs