diff options
| author | Ashutosh Bapat | 2011-06-28 02:35:39 +0000 |
|---|---|---|
| committer | Ashutosh Bapat | 2011-06-28 02:35:39 +0000 |
| commit | 51355d7b7c7cde644fd754ace4e21b746840e4f9 (patch) | |
| tree | 38add6e2e813682ccf8cc5746b225503db45d58a /src/backend/optimizer | |
| parent | 1401d725b719ac2b6de45ace6e6bfd1a7413bc66 (diff) | |
The commit fixes two issues
FIRST
If for an aggregate function, collection function does not exist, we need to
collect the raw data from the data nodes and apply the transition and
finalization phases of such an aggregate on coordinator itself, i.e. such
an aggregate can not be pushed to the datanode. In PGXC, such aggregates are
indicated by invalid collection function oid in pg_aggregate.
In case of aggregates, array_agg and string_agg, the transition result type is
'internal'. These aggregates use internals structures such as ArrayBuildState
and StringInfo resp. as transition results. The clients (in this case
coordinator) can not handle transition results of 'internal' type. Hence setting
invalid collection function oid for these aggregates.
SECOND
For aggregates which use polymorphic transition types, those polymorphic types
need to be resolved before creating tuple descriptors for the remote query being
pushed to the datanode with these types of aggregates. The polymorphic
transition types are resolved during the execution phase where as the tuple
descriptor is created at planning time. Hence for now, aggregates with
polymorphic transition result types are not pushed to the datanodes.
Diffstat (limited to 'src/backend/optimizer')
| -rw-r--r-- | src/backend/optimizer/plan/createplan.c | 25 |
1 files changed, 21 insertions, 4 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index a96619b112..19c8bd2c00 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -5452,9 +5452,9 @@ pgxc_process_grouping_targetlist(PlannerInfo *root, List **local_tlist) /* * Walk through the target list and find out whether we can push the - * aggregates and grouping to datanodes. We can do so if the target list - * contains plain aggregates (without any expression involving those) and - * expressions in group by clauses only (last one to make the query legit. + * aggregates and grouping to datanodes. Also while doing so, create the + * targetlist for the query to be shipped to the datanode. Adjust the local + * targetlist accordingly. */ foreach(temp, *local_tlist) { @@ -5465,7 +5465,24 @@ pgxc_process_grouping_targetlist(PlannerInfo *root, List **local_tlist) if (IsA(expr, Aggref)) { Aggref *aggref = (Aggref *)expr; - if (aggref->aggorder || aggref->aggdistinct || aggref->agglevelsup) + /* + * If the aggregation needs tuples ordered specifically, or only + * accepts distinct values, we can not aggregate unless we have all + * the qualifying rows. Hence partial aggregation at data nodes can + * give wrong results. Hence we can not such aggregates to the + * datanodes. + * If there is no collection function, we can not combine the + * partial aggregation results from the data nodes, hence can not + * push such aggregate to the data nodes. + * PGXCTODO: If the transition type of the collection is polymorphic we + * need to resolve it first. That tells us the partial aggregation type + * expected from data node. + */ + if (aggref->aggorder || + aggref->aggdistinct || + aggref->agglevelsup || + !aggref->has_collectfn || + IsPolymorphicType(aggref->aggtrantype)) { shippable_remote_tlist = false; break; |
