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

On Sun, Feb 6, 2011 at 9:10 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Suppose "foo" is toasted.  As the code stands in master, it gets detoasted in
>> text_lt().  Certainly we won't overwrite the source back in PL/pgSQL from the
>> detoast point in text_lt().
>
> Right, that much seems obvious...
>
>> Pavel's optimization requires that we identify the
>> need to detoast the datum earlier and do so preemptively.
>
> I guess I need to look at the patch more.  I'm failing to understand
> why that can't be done within one or two functions, without passing
> around a new piece of state.

So it looks like there are only two places that set
should_be_detoasted to something other than false.

plpgsql_exec_function does this:

var->should_be_detoasted = !var->isnull &&
!var->datatype->typbyval
&& var->datatype->typlen == -1;

And exec_assign_value does this, which appears to be the same test in
a different guise:

if (!var->datatype->typbyval && !*isNull)
{
var->freeval = true;
var->should_be_detoasted = var->datatype->typlen == -1;
}

Every other place where we set this flag, we appear to already know
either that the value is null or that it can't be toasted anyhow. So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:

!var->isnull && var->datatype->typbyval && var->datatype->typlen == -1
&& VARATT_IS_EXTENDED(var->value)

I haven't tested this, but it's not clear that'd be measurably slower
than checking a single Boolean.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company