Hello
2011/1/25 Noah Misch <noah@leadboat.com>:
> On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
>> because I am not sure so any complex solution can be done to deadline
>> for 9.1, I created a patch that is based on Tom ideas - just
>> explicitly detoast function parameters.
>
> I can confirm that, for your original test case, this yields performance
> comparable to that of your original patch.
I know it :(. I am thinking, so detoasting on usage is better, but I
am don't know more about Tom or Rober's plans.
>
> This patch hooks into plpgsql_exec_function, detoasting only the function
> arguments. Therefore, it doesn't help in a test case like the one I posted in
> my original review. That test case initialized a variable using SELECT INTO,
> then used the variable in a loop. Is there any benefit to doing this in
> plpgsql_exec_function, versus exec_assign_value (Tom's suggestion), which would
> presumably help the other test case also?
I can explicitly detosting on assign stmt too. It's 6 lines more.
Regards
Pavel
>
> As we've discussed, unlike the original patch, this yields similarly grand
> performance regressions on functions that receive toasted arguments and never
> use them. Who is prepared to speculate that this will help more people than it
> will hurt? This patch is easier on -hackers than the original, but it seems
> much more likely to create measurable performance regressions in the field.
> It's clear the committers prefer it this way, but I remain skeptical.
>
> nm
>
