-
- Downloads
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated hashtable neglected the possibility that the Agg node might reference PARAM_EXEC Params that are not referenced by its input plan node. That's okay if the Params are in upper tlist or qual expressions; but if one appears in aggregate input expressions, then the hashtable contents need to be recomputed when the Param's value changes. To avoid unnecessary performance degradation in the case of a Param that isn't within an aggregate input, add logic to the planner to determine which Params are within aggregate inputs. This requires a new field in struct Agg, but fortunately we never write plans to disk, so this isn't an initdb-forcing change. Per report from Jeevan Chalke. This has been broken since forever, so back-patch to all supported branches. Andrew Gierth, with minor adjustments by me Report: <CAM2+6=VY8ykfLT5Q8vb9B6EbeBk-NGuLbT6seaQ+Fq4zXvrDcA@mail.gmail.com>
Showing
- src/backend/executor/nodeAgg.c 6 additions, 4 deletionssrc/backend/executor/nodeAgg.c
- src/backend/nodes/copyfuncs.c 1 addition, 0 deletionssrc/backend/nodes/copyfuncs.c
- src/backend/nodes/outfuncs.c 1 addition, 0 deletionssrc/backend/nodes/outfuncs.c
- src/backend/nodes/readfuncs.c 1 addition, 0 deletionssrc/backend/nodes/readfuncs.c
- src/backend/optimizer/plan/createplan.c 1 addition, 0 deletionssrc/backend/optimizer/plan/createplan.c
- src/backend/optimizer/plan/subselect.c 47 additions, 1 deletionsrc/backend/optimizer/plan/subselect.c
- src/include/nodes/plannodes.h 2 additions, 1 deletionsrc/include/nodes/plannodes.h
- src/test/regress/expected/aggregates.out 75 additions, 0 deletionssrc/test/regress/expected/aggregates.out
- src/test/regress/sql/aggregates.sql 22 additions, 0 deletionssrc/test/regress/sql/aggregates.sql
Loading
Please register or sign in to comment