2011/1/18 Tom Lane <t...@sss.pgh.pa.us>:
> Noah Misch <n...@leadboat.com> writes:
>> On Sun, Jan 16, 2011 at 06:49:27PM +0100, Pavel Stehule wrote:
>>> I am sending a updated version with little bit more comments. But I am
>>> sure, so somebody with good English have to edit my comments.
>>> Minimally I hope, so your questions will be answered.
>
>> Thanks. I edited the comments and white space somewhat, as attached. I'll
>> go
>> ahead and mark it Ready for Committer.
>
> 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? If it's to avoid detoasting when
> the variable is read in a way that doesn't require detoasting, it fails
> rather completely IMO, since exec_eval_datum certainly doesn't know
> that.
I am not sure about false overhead of detoasting. This is a safe
variant. I don't would to decrease performance. Not sure if it's
necessary.
But detoasting on assignment isn't enought:
some most simple example - searching a maximum
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. So there is necessary to
modify a process. Detoast not on assign, but detoast on usage.
Regards
Pavel Stehule
>
> The added memory context variable seems redundant as well.
I didn't find a pointer on top execution context available from
execution state. I am sure, so we have to switch to this context
explicitly.
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
