2016-08-24 17:08 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>:
> Andrew Gierth <and...@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.
>
> It looks like it's sufficient to do this:
>
> diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/
> nodeAgg.c
> index 1ec2515..f468fad 100644
> *** a/src/backend/executor/nodeAgg.c
> --- b/src/backend/executor/nodeAgg.c
> *************** ExecReScanAgg(AggState *node)
> *** 3425,3435 ****
> return;
>
> /*
> ! * 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.
Regards
Pavel
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
