aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistbuildbuffers.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-08-24 14:37:50 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-08-24 14:38:13 -0400
commit616be05dfea09e8221e190086c0d75351f3a57ca (patch)
tree2e8facc34f3b5e2b0a4f49dd7eac6f0412276666 /src/backend/access/gist/gistbuildbuffers.c
parenteaae83c123f5e8e103abbbe822fe73b791d9d5c9 (diff)
downloadpostgresql-616be05dfea09e8221e190086c0d75351f3a57ca.tar.gz
postgresql-616be05dfea09e8221e190086c0d75351f3a57ca.zip
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>
Diffstat (limited to 'src/backend/access/gist/gistbuildbuffers.c')
0 files changed, 0 insertions, 0 deletions