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
