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

2011/1/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2011/1/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>