Re: Faster setup_param_list() in plpgsql

On 03/14/2015 06:04 PM, Tom Lane wrote:
> Given the rather hostile response I got to
> http://www.postgresql.org/message-id/4146.1425872254@sss.pgh.pa.us
> I was not planning to bring this topic up again until 9.6 development
> starts. However, as I said in that thread, this work is getting done now
> because of $dayjob deadlines, and I've realized that it would actually
> make a lot of sense to apply it before my expanded-arrays patch that's
> pending in the current commitfest. So I'm going to put on my flameproof
> long johns and post it anyway. I will add it to the 2015-06 commitfest,
> but I'd really rather deal with it now ...
>
> What this patch does is to remove setup_param_list() overhead for the
> common case of PLPGSQL_DTYPE_VAR variables (ie, any non-composite type).
> It does that by the expedient of keeping the ParamExternData image of such
> a variable valid at all times. That adds a few cycles to assignments to
> these variables, but removes more cycles from each use of them. Unless
> you believe that common plpgsql functions contain lots of dead stores,
> this is a guaranteed win overall.
>
> I'm seeing about 10% overall speedup (vs HEAD, with casserts off) for
> realistic simple plpgsql logic, such as this test case:
>
> create or replace function typicalspeed(n int) returns bigint as $$
> declare res bigint := 0;
> begin
> for i in 1 .. n loop
> res := res + i;
> if i % 10 = 0 then res := res / 10; end if;
> end loop;
> return res;
> end
> $$ language plpgsql strict stable;
>
> For functions with lots of variables (or even just lots of expressions,
> since each one of those is a PLpgSQL_datum too), it's even more helpful.
> I have found no cases where it makes things worse, at least to within
> measurement error (run-to-run variability is a percent or two for me).
>
> The reason I would like to apply this now rather than wait for 9.6
> is that by making parameter management more explicit it removes the
> need for the klugy changes in exec_eval_datum() that exist in
> http://www.postgresql.org/message-id/22945.1424982755@sss.pgh.pa.us
> Instead, we could leave exec_eval_datum() alone and substitute read-only
> pointers only when manufacturing the parameter image of an expanded-object
> variable. If we do it in the other order then we'll be making an API
> change for exec_eval_datum() in 9.5 (assuming said patch gets in) and then
> reverting it come 9.6.
>
> So there you have it. Now, where'd I put those long johns ...
>
>

I'm inclined to say go for it. I can recall cases in the past where we
have found some significant piece of work to be necessary after feature
freeze in order to enable a piece of work submitted before feature
freeze to proceed. This sounds like a similar case.

cheers

andrew