diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-08-24 14:37:50 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-08-24 14:38:12 -0400 |
commit | 2c00fad2864350508f666da1a2c04e0cbe9cbf58 (patch) | |
tree | 15c1158e56998cd9f46b10bd5664cf18b6451297 /contrib/postgres_fdw/postgres_fdw.c | |
parent | 5cd3864075622b203d530f1a710818777859304e (diff) | |
download | postgresql-2c00fad2864350508f666da1a2c04e0cbe9cbf58.tar.gz postgresql-2c00fad2864350508f666da1a2c04e0cbe9cbf58.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 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions