Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date
Msg-id AANLkTi=OqeeX3_0rY1keXpNQvQ1RV_thQ1KJXhT_ycZ7@mail.gmail.com
Whole thread Raw
In response to Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pl/python refactoring
Next
From: Jim Nasby
Date:
Subject: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED