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

From Noah Misch
Subject Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date
Msg-id 20110125010320.GB20879@tornado.leadboat.com
Whole thread Raw
In response to Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.

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?

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Patch to add a primary key using an existing index
Next
From: Itagaki Takahiro
Date:
Subject: Re: Per-column collation, the finale