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

Hello

2011/1/25 Noah Misch <noah(at)leadboat(dot)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
>