Re: Is it possible and worthy to optimize scanRTEForColumn()?

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: Is it possible and worthy to optimize scanRTEForColumn()?
Дата
Msg-id
20171208193511.2xn2tbwetxsvey23@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
Is it possible and worthy to optimize scanRTEForColumn()? Rui Hai Jiang <ruihaijiang@msn.com>
Re: Is it possible and worthy to optimize scanRTEForColumn()? Tom Lane <tgl@sss.pgh.pa.us>
Re: Is it possible and worthy to optimize scanRTEForColumn()? Andres Freund <andres@anarazel.de>
Re: Is it possible and worthy to optimize scanRTEForColumn()? Tom Lane <tgl@sss.pgh.pa.us>
Re: Is it possible and worthy to optimize scanRTEForColumn()? Andres Freund <andres@anarazel.de>
On 2017-12-08 10:05:17 -0500, Tom Lane wrote:
> I'm not particularly concerned about it --- I've not seen profiles
> suggesting that that function is a big time sink.  Tables with very
> many columns tend to be inefficient for lots of reasons, and I rather
> doubt that this particular place is the first thing to hit if you
> want to make that better.

FWIW, I've definitely seen scanRTEForColumn() show up in profiles.  In
some of those cases the issue could be worked around by mostly using
prepared statements.  But it definitely can be painful, not that
surprising given the the complexity is essentially
O(#available-columns * #looked-up-columns).

However I don't think a microoptimization, even if it were correct, as
breaking earlier out of the loop would help meaningfully. We'd need a
different datastructure.

Greetings,

Andres Freund

В списке pgsql-hackers по дате отправления
От: Robins Tharakan
Дата:
Сообщение: Typo in recent commit
От: Tom Lane
Дата:
FAQ