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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Mikhail Balayan
Дата:
Сообщение: Re: Automatic aggressive vacuum on almost frozen table takes too long
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: can't get psql authentication against Active Directory working