Re: Faster setup_param_list() in plpgsql - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: Faster setup_param_list() in plpgsql |
Date | |
Msg-id | 55061AA4.203@dunslane.net Whole thread Raw |
In response to | Faster setup_param_list() in plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
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
pgsql-hackers by date: