Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

nodeAgg.c

  • Tom Lane's avatar
    e6336b8b
    Save a few cycles in advance_transition_function(). · e6336b8b
    Tom Lane authored
    Keep a pre-initialized FunctionCallInfoData in AggStatePerAggData, and
    re-use that at each row instead of doing InitFunctionCallInfoData each
    time.  This saves only half a dozen assignments and maybe some stack
    manipulation, and yet that seems to be good for a percent or two of the
    overall query run time for simple aggregates such as count(*).  The cost
    is that the FunctionCallInfoData (which is about a kilobyte, on 64-bit
    machines) stays allocated for the duration of the query instead of being
    short-lived stack data.  But we're already paying an equivalent space cost
    for each regular FuncExpr or OpExpr node, so I don't feel bad about paying
    it for aggregate functions.  The code seems a little cleaner this way too,
    since the number of things passed to advance_transition_function decreases.
    e6336b8b
    History
    Save a few cycles in advance_transition_function().
    Tom Lane authored
    Keep a pre-initialized FunctionCallInfoData in AggStatePerAggData, and
    re-use that at each row instead of doing InitFunctionCallInfoData each
    time.  This saves only half a dozen assignments and maybe some stack
    manipulation, and yet that seems to be good for a percent or two of the
    overall query run time for simple aggregates such as count(*).  The cost
    is that the FunctionCallInfoData (which is about a kilobyte, on 64-bit
    machines) stays allocated for the duration of the query instead of being
    short-lived stack data.  But we're already paying an equivalent space cost
    for each regular FuncExpr or OpExpr node, so I don't feel bad about paying
    it for aggregate functions.  The code seems a little cleaner this way too,
    since the number of things passed to advance_transition_function decreases.