Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5
От | David Rowley |
---|---|
Тема | Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5 |
Дата | |
Msg-id | CAApHDvpPdBTYBmR4yxpphNkP+ULmzPAOfqzf0=QUTycDtP7Bhg@mail.gmail.com обсуждение исходный текст |
Ответ на | 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>) |
Ответы |
Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5
|
Список | pgsql-general |
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 по дате отправления: