Let's see if I can summarize the facts we've collected so far. I see four options based on the discussion:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch(). Essentially Pavel's original patch, only with the check logic moved up from exec_eval_datum() to plpgsql_param_fetch() to avoid bothering a couple other callers that would not benefit. Tom and Robert objected to the new bookkeeping. 2. Deduce the need to detoast and do so in plpgsql_param_fetch(). Avoids the new bookkeeping. Tom objected to the qualitative performance implications, and Pavel measured a 3% performance regression. 3. Deduce the need to detoast and do so in exec_assign_value(). Tom's proposal. This avoids the new bookkeeping and does not touch a hot path. It could eliminate a datum copy in some cases. Pavel, Noah, Heikki and Robert objected to the detoasts of never-referenced variables. 4. Change nothing. Or to perhaps put it even simpler: 1. Swallow some ugly bookkeeping. 2. Slow down a substantial range of PL/pgSQL code to a small extent. 3. Slow down unused-toasted-variable use cases to a large extent. 4. Leave the repeated-detoast use cases slow to a large extent. In principle, given access to a global profile of PL/pgSQL usage, we could choose objectively between #2, #3 and #4. I can't see an objective method for choosing between #1 and the others; we'd need a conversion factor between the value of the performance improvement and the cost of that code. In practice, we're in wholly subjective territory. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
