summaryrefslogtreecommitdiff
path: root/src/backend/optimizer
diff options
context:
space:
mode:
authorAshutosh Bapat2011-06-28 02:35:39 +0000
committerAshutosh Bapat2011-06-28 02:35:39 +0000
commit51355d7b7c7cde644fd754ace4e21b746840e4f9 (patch)
tree38add6e2e813682ccf8cc5746b225503db45d58a /src/backend/optimizer
parent1401d725b719ac2b6de45ace6e6bfd1a7413bc66 (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.c25
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;