2011/2/8 Robert Haas <robertmh...@gmail.com>:
> On Sun, Feb 6, 2011 at 9:10 AM, Robert Haas <robertmh...@gmail.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.
Probably less than 1-3%. I tested situation where these checks was
when Datum was used. Assignment is less often, so some shortcut there
these isn't not too important.
Pavel
p.s. There is lot of uneffectivity in assignment statement - different
typoid, typmod means IO cast, so 1-3% from these checks doesn't play a
big role.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
