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