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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Дата
Msg-id AANLkTimR7Pqum=_ZjE3ZpbdQz-ELqc9eosB9FJy8Gtgs@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
2011/2/8 Robert Haas <robertmhaas@gmail.com>:
> On Sun, Feb 6, 2011 at 9:10 AM, Robert Haas <robertmhaas@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
>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Re: Add ENCODING option to COPY
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql