Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5
От | Tom Lane |
---|---|
Тема | Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5 |
Дата | |
Msg-id | 3565866.1676905129@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: A performance issue in ROW_NUMBER() OVER(ORDER BY NULL) [27 times slow than OVER()] V14.5 (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-general |
David Rowley <dgrowleyml@gmail.com> writes: > On Mon, 20 Feb 2023 at 13:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. > 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. The right way to do this would be to pass forward information about which window sort columns had been deemed redundant during make_pathkeys_for_sortclauses: there are a lot more ways for that to happen than "it's a constant". The recent addition of make_pathkeys_for_sortclauses_extended would make it pretty easy for make_pathkeys_for_window to obtain a reduced list of SortGroupClauses, and then in theory you could match that against the original lists to identify which sort columns are redundant (though repeated keys might make that tricky; might be better to provide another more-direct output representation). Pass the information forward in WindowAggPath, et voila. I remain doubtful that it's worth the trouble though. > 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. There's some Asserts in nodeWindowAgg.c about ordNumCols being positive, probably related. regards, tom lane
В списке pgsql-general по дате отправления: