2011/1/18 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> 2011/1/18 Tom Lane <t...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
