• Tom Lane's avatar
    Allocate ParamListInfo once per plpgsql function, not once per expression. · 21dcda27
    Tom Lane authored
    setup_param_list() was allocating a fresh ParamListInfo for each query or
    expression evaluation requested by a plpgsql function.  There was probably
    once good reason to do it like that, but for a long time we've had a
    convention that there's a one-to-one mapping between the function's
    PLpgSQL_datum array and the ParamListInfo slots, which means that a single
    ParamListInfo can serve all the function's evaluation requests: the data
    that would need to be passed is the same anyway.
    
    In this patch, we retain the pattern of zeroing out the ParamListInfo
    contents during each setup_param_list() call, because some of the slots may
    be stale and we don't know exactly which ones.  So this patch only saves a
    palloc/pfree per evaluation cycle and nothing more; still, that seems to be
    good for a couple percent overall speedup on simple-arithmetic type
    statements.  In future, though, we might be able to improve matters still
    more by managing the param array contents more carefully.
    
    Also, unify the former use of estate->cur_expr with that of
    paramLI->parserSetupArg; they both were used to point to the active
    expression, so we can combine the variables into just one.
    21dcda27
plpgsql.h 26.9 KB