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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
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 00:17:45
Message-ID: 3452823.1676852265@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I suspect ed1a88dda would be what made this faster in master. We'll
> check for peer rows to check "NULL IS NOT DISTINCT FROM NULL" prior to
> that change with the ORDER BY NULL query.

Mmm, yeah, probably so: "order by null rows between unbounded preceding
and current row" has about the same performance in v15 as HEAD has
with just "order by null".

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.) Getting rid of the useless targetlist column altogether would
be way more invasive, and I'm not inclined to try.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Puja Anil AJMERA 2023-02-20 04:12:17 Need Detailed to build real time CDC Data Pipeline
Previous Message David Rowley 2023-02-19 23:26:17 Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5