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>
Branch
------
REL9_3_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/aaad96e4026e7bb3033ac0127510f2c60116a1b3
Modified Files
--------------
src/backend/executor/nodeAgg.c | 15 ++++---
src/backend/nodes/copyfuncs.c | 1 +
src/backend/nodes/outfuncs.c | 1 +
src/backend/optimizer/plan/createplan.c | 1 +
src/backend/optimizer/plan/subselect.c | 47 +++++++++++++++++++-
src/include/nodes/plannodes.h | 2 +
src/test/regress/expected/aggregates.out | 73 ++++++++++++++++++++++++++++++++
src/test/regress/sql/aggregates.sql | 22 ++++++++++
8 files changed, 155 insertions(+), 7 deletions(-)
