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 по дате отправления