|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Faster setup_param_list() in plpgsql|
|Views:||Raw Message | Whole Thread | Download mbox|
Given the rather hostile response I got to
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;
for i in 1 .. n loop
res := res + i;
if i % 10 = 0 then res := res / 10; end if;
$$ 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
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 ...
regards, tom lane
|Next Message||Pavel Stehule||2015-03-14 23:55:46||Re: pg_dump quietly ignore missing tables - is it bug?|
|Previous Message||Peter Geoghegan||2015-03-14 20:30:00||Re: Re: Abbreviated keys for Datum tuplesort|