Fix improper repetition of previous results from a hashed aggregate

Enterprise / PostgreSQL - Tom Lane [sss.pgh.pa.us] - 24 August 2016 13:38 UTC

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:

2c00fad Fix improper repetition of previous results from a hashed aggregate.
src/backend/executor/nodeAgg.c | 10 ++--
src/backend/nodes/copyfuncs.c | 1 +
src/backend/nodes/outfuncs.c | 1 +
src/backend/nodes/readfuncs.c | 1 +
src/backend/optimizer/plan/createplan.c | 1 +
src/backend/optimizer/plan/subselect.c | 48 ++++++++++++++++++-
src/include/nodes/plannodes.h | 3 +-
src/test/regress/expected/aggregates.out | 75 ++++++++++++++++++++++++++++++
src/test/regress/sql/aggregates.sql | 22 +++++++++
9 files changed, 156 insertions(+), 6 deletions(-)

Upstream: git.postgresql.org


  • Share