]> granicus.if.org Git - postgresql/commit
Fix improper repetition of previous results from a hashed aggregate.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 24 Aug 2016 18:37:50 +0000 (14:37 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 24 Aug 2016 18:38:13 +0000 (14:38 -0400)
commit616be05dfea09e8221e190086c0d75351f3a57ca
tree2e8facc34f3b5e2b0a4f49dd7eac6f0412276666
parenteaae83c123f5e8e103abbbe822fe73b791d9d5c9
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>
src/backend/executor/nodeAgg.c
src/backend/nodes/copyfuncs.c
src/backend/nodes/outfuncs.c
src/backend/nodes/readfuncs.c
src/backend/optimizer/plan/createplan.c
src/backend/optimizer/plan/subselect.c
src/include/nodes/plannodes.h
src/test/regress/expected/aggregates.out
src/test/regress/sql/aggregates.sql