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 AANLkTi=OqeeX3_0rY1keXpNQvQ1RV_thQ1KJXhT_ycZ7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
2011/1/18 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2011/1/18 Tom Lane <tgl@sss.pgh.pa.us>:
>>> I looked at this patch and found it fairly awkward.  What is the point
>>> of adding an additional flag to every variable, as opposed to just
>>> forcibly detoasting during assignment?
>
>> But detoasting on assignment isn't enought:
>
>> for i in array_lower(a,1) .. array_upper(a,1)
>> loop
>>   if x < a[i] then
>>     x = a[i];
>>   end if;
>> end loop;
>
>> in this cycle the variable a wasn't modified. Any access to this
>> variable means a detoast and decompres.
>
> How so?  In what I'm envisioning, a would have been decompressed when it
> was originally assigned to.
>

oh, I understand now. I afraid so it can be overhad, because there can
be path where you doesn't use a some variables from parameter list.

There are lot of user procedures, where not all parameters are used,
so I think is better to wait on first usage. Probably these procedures
can be written in SQL or C, but it can decrese a performance of some
current trivial functions in plpgsql.  So my strategy is simple - wait
with detoasting to last moment, but don't repeat detoasting. My
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost use cases (problem is thousands
detoasting).

Regards

Pavel Stehule



>                        regards, tom lane
>


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pl/python refactoring
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED