Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > Something is wrong with the way chgParam is being handled in Agg nodes. > The code in ExecReScanAgg seems to assume that if the lefttree doesn't > have any parameter changes then it suffices to re-project the data from > the existing hashtable; but of course this is nonsense if the parameter > is in an input to an aggregate function.
/* ! * If we do have the hash table and the subplan does not have any ! * parameter changes, then we can just rescan the existing hash table; ! * no need to build it again. */ ! if (outerPlan->chgParam == NULL) { ResetTupleHashIterator(node->hashtable, &node->hashiter); return; --- 3425,3436 ---- return;
/* ! * If we do have the hash table and there are no relevant parameter ! * changes, then we can just rescan the existing hash table; no need ! * to build it again. */ ! if (node->ss.ps.chgParam == NULL && ! outerPlan->chgParam == NULL) { ResetTupleHashIterator(node->hashtable, &node->hashiter); return;
I'm not sure if it's worth trying to distinguish whether the Param is inside any aggregate calls or not. The existing code gets the right answer for
select array(select x+sum(y) from generate_series(1,3) y group by y) from generate_series(1,3) x;
and we'd be losing some efficiency for cases like that if we fix it as above. But is it worth the trouble?
The result should not depend on GUC - hashagg on/off changing output - it is error.