Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql

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